So, I just generated a new set of RSA keys the other day. The first time I connected to github via SSH, I was asked to verify the fingerprint and type 'yes'. I verified and accepted. I then got a warning that github would be permanently added to my known_hosts file. No problem there... that's what's supposed to happen. However... when I pushed to github this morning, I got another warning. This time, no fingerprint, it just warned me that github would be added to my known_hosts list. What's the deal?submitted by joe_temp
That was exactly what I had in mind (and I assume Àlex as well), and it would be a great way to leverage one of Plasma’s biggest strengths: Flexibility, which offers choice! Of course maintaining multiple Plasmoids for the same purpose also means multiplied work, but not all Plasmoids have to be created by the core Plasma team. Everyone can write a Plasmoid for a certain purpose, add the X-Plasma-Provides line to the desktop file and thereby plug it right into this system! With this in place, whenever a user complains that a Plasmoid is either too complex or offers too little choice and an alternative exists, we can point them to it and they can easily switch.
The Netrunner distribution is a project based upon the Ubuntu operating system. Netrunner strives to be an easy to use desktop operating system that completes most tasks with free software while offering convenient add-ons and web-based solutions to round out the user experience. Netrunner ships with the KDE desktop to provide a mix of flexibility (for power users) and familiarity (for newcomers). The latest release of Netrunner, version 13.12, is based upon Ubuntu 13.10. The distribution comes with several appealing features, including multimedia support, Windows application compatibility via WINE and the Steam gaming portal software. Netrunner is available in just one edition and can be downloaded in 32-bit or 64-bit x86 builds. The project's installation media is approximately 1.6 GB in size.
On average once a week I take a look at the logs and various security related emails that I get from various things I have set up. What tipped me off that there was a problem was SELinux. SELinux really works and I am very glad we had it enabled in this case. I was notified that there had been an SELinux denial on an application server where apache was trying to run ls. Our apache should not normally be doing that. Looking at the full logs I found that there were 2869 denials in the audit log all between Sat 01 Feb 2014 06:01:29 AM PST and Sat 01 Feb 2014 11:01:30 AM PST and then no more. SELinux denials are an excellent way of detecting unauthorized activity.
The attacker had found a vulnerable app which led to shell access but was restricted to the httpd_t security context. They tried and failed to execute df, perl, ps, sh, where, which, ping, iptables, ifconfig, ls, and tried to access various parts of the filesystem and were all denied. I can just imagine their frustration at having a shell but not being able to do anything with it!
They tried to ftp and scp out and found SELinux blocking all of their outbound connection attempts due to the httpd_can_network_connect SELinux setting being off. BUT... httpd_can_network_connect_db is necessarily on so that the app can connect to the database server. They found that they were able to get out of the box using port 3306. It seems they tried to connect to MySQL on a number of IPs in our external IP range (perhaps not having realized that the box is behind a firewall on an internal private network). Fortunately, our firewall's default deny egress policy prevented them from getting to any databases that way so that's another useful security control. This is a good example of why the PCI DSS (and best practice in general) requires egress filtering.
This was default SELinux configuration on CentOS 5.10, right out of the box. No custom policy or anything.
SELinux really saved us here. Have any of you had a similar experience?submitted by iheartrms
[link] [5 comments]