I assume you mean root console access, yes if you have physical access to the machine as root there is nothing stopping you. With SELinux properly configured you cannot easily preform an escalation of privileges attack since you can only access whatever the process you were exploiting can access.
SELinux covers both of the threats you mentioned proactively if setup correctly, as mentioned in the article I posted. Quoted from the article… Notice the one line configuration to ensure the website contents are secure. >> allow httpd_t httpd_sys_content_t:file read; >> Think about this for a moment. Even if all the files in /var/www/html are >> owned by Apache and chmodded 777, SELinux will prevent httpd_t from WRITING >> to those files. If a 0-day comes out that allows an attacker to access the >> filesystem as Apache, he’s also accessing the filesystem as httpd_t, and >> SELinux won’t allow him to change the contents of your website, since >> httpd_t is only allowed READ access. He also can’t do much outside of >> /var/www/html, since we haven’t allowed httpd_t to access anything else >> other than httpd_sys_content_t types. >> Daniel. On 11/03/2014, at 9:34 pm, Steve Holdoway <[email protected]> wrote: > If you have root access, then what's to stop you disabling selinux? Can you > lock /selinux/enforce, and the boot config? If you can, then how to reverse > to update the server? > > Personally I reckon the two biggest threats to a web server are > > - compromising the site content, installation of malware/ASB logins, etc. > against which I have a different list of precautions.... > - not addressing known security flaws in common CMSes in a timely manner > > Cheers, > > Steve > > On 11/03/14 19:46, Daniel Rammelt wrote: >> The biggest threat for a web server, is exploiting a vulnerability and >> gaining root access. How are you going to restrict access to files for root >> with standard permissions? >> >> The ability to restrict not only what files but which commands a user can >> access, and what files a process can access is amazing. >> >> I agree you can shore up a server pretty tight with the standard tools, but >> SELinux just takes it that step further and if used correctly makes if far >> simpler to manage. I see the old way as micro managing, and its a lot easier >> to make mistakes when doing so. >> I see KISS used a lot to imply that the simpler the tool the better, I see >> it as the simpler to configure the better. And SELinux falls into the latter >> category IMO. >> >> This is an article I found helpful when setting up SELinux the first time >> round. Related to Apache. I would be interested in how you could accomplish >> something like this without SELinux? >> http://isrlabs.net/wordpress/?p=129 > Sure. Have a read up on chattr. CMSes require only read access to most of the > docroot, writes to others. Writeable directories have to stay writeable, with > or without SELinux. You can lock it all down, except for root... see initial > point re disabling. >> >> And this is the video that stopped me disabling SELinux… Skip to about 4:30 >> if you want to skip the introduction and get to the presentation proper. >> https://www.youtube.com/watch?v=MxjenQ31b70 >> >> Daniel. >> >>> Personally cannot think of a single use case for "if the file is under >>> this directory, I want permissions XYZ" which can't be delivered by the >>> current MAC/DAC/umask system... well, not one I'd want to see on a >>> production server - KISS is paramount! Use of secondary groups+setgid >>> +(rarely) umask+pam.d changes has done just about everything I need* >>> >>> Steve >> >> >> >> _______________________________________________ >> Linux-users mailing list >> [email protected] >> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users > > _______________________________________________ > Linux-users mailing list > [email protected] > http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
