Thanks for your support on this one John,
Often I have seen frustrated sysadmins who can't get things to work
because SELinux is getting the way, just diving in with
chmod 777 -R * to try and fix a problem, making hard for the sysadmin is
not going to improve security, however glamorous, complex
or elegant the solution is. KIS is the order of the day for the best
security.
Another thing I have noticed is SELinux forces some system packages to
deliver meaningless errors: one such example on one of our webservers
was httpd was complaining the directory for a website didn't exist, when
clearly it did. What was really happening buried in the logs
was good old SELinux was denying httpd access to its own html
directories (which is a bonkers thing to do), the error from httpd
was therefore competely meaningless, yet another example of SELinux
making it tougher for the sysadmin.
Additionally dump/restore the staple diet of Linux backup and DR doesn't
back up this extra ACL baggage yet, so its useless to most people.
The best thing to do is add this to /etc/selinux/config
SELINUX=disabled
And then get on with the real jobs....
Note this still doesn't get rid of those damn ACL crap buried in the
filesystem so dump still complains, so I pipe the output to grep -v "ACL"
:-)
P.
John Logsdon wrote:
>I would agree with Peter on SEL and I have it disabled even though of
>course the userland tools are still SEL-modified and we have to use
>libselinux everywhere.
>
>{rant}
>
>One thing that is incredibly annoying with the packaging of *all* Linuxes
>that I have seen is the sloppy access controls even in the so-called
>paranoid settings, which only apply to the firewall aspects really.
>Maybe there are exceptions but even the installation scripts leave files
>644 or similar when they only need to be 600. If a file is in user and
>group for root, then apart from the few other system users that are also
>members of the root group, 600 is perfectly adequate or 611 if it's a
>directory and 'go' want to access files within the directory. I wish the
>package providers would realise this.
>
>At the user level, RH (? was it them?) started off the fashion of giving
>every user their own group. So groups become immediately pointless.
>Debian put all users in the same group users - almost as silly. Groups
>enable a very powerful control mechanism and ignoring them removes at
>least one dimension from the security.
>
>I know next to nothing about NT controls so I can't comment on whether
>Linux 'meets' some arbitrary requirements but by (a) limiting access to
>system files to root (ie the user) and those few other users and (b)
>fluent use of groups it is possible to use the DAC to close down almost
>everything.
>
>And to finish the job, use grsecurity which is fairly easy to configure -
>it appears to be much easier than SEL in particular - and doesn't need any
>userland tools as it is entirely in the kernel.
>
>{\rant}
>
>Sorry about that!
>
>John
>
>John Logsdon "Try to make things as simple
>Quantex Research Ltd, Manchester UK as possible but not simpler"
>j.logsdon@xxxxxxxxxxxxxxxxxxxx a.einstein@xxxxxxxxxxxxxx
>+44(0)161 445 4951/G:+44(0)7717758675 www.quantex-research.com
>
>
>On Tue, 24 May 2005, Peter Farrow wrote:
>
>
>
>>Maybe so... and if it works for you then use it, but sometimes when
>>people say "but we needed this or we needed that", they haven't
>>allways sat down and thought "why do we need it" or "do we really 'need'
>>this ?"
>>
>>Even having worked on government classified networks I have *never* seen
>>an instance where the standard access controls offered by Linux/Unix
>>didn't do what was required.
>>
>>Often DAC/MAC setups leads to inferior security because they can get
>>very complex to setup, and the term "can't see the wood for the trees"
>>springs to mind.
>>
>>As is most often the case the best security is the simplest, and DAC/MAC
>>bloat doesn't help in any way.
>>
>>If some document or requirement or spec says you need it, I would often
>>question the theory behind the spec, and only if a demonstrable need
>>arises (have yet to see that in 20+ years of consulting) then I would do
>>it...
>>
>>Of course I've also been in this game too long as well to "never say
>>never" and there is always a first time.... :-)
>>
>>P.
>>
>>
>>
>>
>>Bryan J. Smith wrote:
>>
>>
>>
>>>On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
>>>
>>>
>>>
>>>
>>>>Just turn off SELinux, it really is a complete pain.
>>>>I've managed to set up Linux and Unix boxes securely for years without
>>>>all the SE Linux baggage.....
>>>>All it does is slow the machine down, and adds "bloat" to the OS...
>>>>
>>>>
>>>>
>>>>
>>>Unfortunately, Mandatory Access Controls (MACs) are a necessary
>>>accountability detail needed in many environments.
>>>
>>>It's really the only place NT was better than legacy UNIX.
>>>
>>>Of course, I would return argue that Linux at least addresses all
>>>aspects of the 7 domains of the SSCP _except_ the MAC portion of
>>>DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as
>>>standard.
>>>
>>>But we needed MAC. It's a good thing to have in many environments --
>>>especially where accountability is essential.
>>>
>>>
>>>
>>>
>>>
>>>
>
>_______________________________________________
>CentOS mailing list
>CentOS@xxxxxxxxxx
>http://lists.centos.org/mailman/listinfo/centos
>
>
