Jim Crilly wrote:
It's been in the stable release of every kernel for quite some time now.
And it's enabled by default in FC5 and maybe RHEL4, I can't remember 100%
about the latter. And I'm not 100% sure what all GRSecurity does, but from
what I remember it covers a different area than SELinux so they're not
comparable.
The main reason it's not enabled by default in most distributions is that
writing good policies is a huge amount of work and they haven't written
policies for all of their packages. Now that SELinux has been pushed into
FC it'll act as motivation for people to get working on those policies so I
would guess that we'll see SELinux be enabled in the rest of the major
distributions by default in their next releases or so.
That is part of my point. The ACL system included with Linux (whether it
be the POSIX ACLs or SELinux) are too complex for use by most system
administrators, and so are overlooked. Actually, that last statement is
untrue - POSIX ACLs seem to be lacking slightly in functionality, and
SELinux is overly complicated (see a previous reply in which someone
else said that). AppArmor seems to be heading along the right tracks,
because it can automatically create its own profiles which you can then
tune as necessary, so it does not require as much work to create a
policy for a service. However, it probably won't be included in the
kernel, especially in the near future (SELinux, which is associated with
the NSA, is already there - why add another one, even if it is more
advanced?)
To varying extents everything is still under research. AFAIK the core of
SELinux hasn't changed in many years, it's just taken this long for people
to figure out how to apply it properly.
And people still don't know how to apply it properly. How many system
administrators do you see using SELinux? In contrast, how many do you
now see using AppArmor, which has not been around anywhere near as long
SELinux?
You can't blame advertising - AppArmor may be backed by Novell, but
SELinux has the recognition of having ties with the NSA. Then what is
it? Ease of use? The fact that a system like that does not have to have
overly complicated usermode tools to configure the ACLs?
Sure if you can break into sshd you might be able to mess with it's config
files and any other areas on the system that everyone has access too, but
that's it. But if you just login via ssh you'll only have access to the
files that your account has access to, not sshd.
Assuming that sshd hasn't been locked down.. What if a vulnerability is
found, and an exploit comes out before a patch, and sshd is compromised?
Or your root password is brute-forced? What happens then? The attacker
has root access, and thus access to EVERYTHING on your server (Windows
has the reference monitor, which can't be tampered with or turned off...
But we'll leave that aside for now). And unless you have bound sshd to a
non-default port above 1023, you have to run it as root - but are you
willing to sacrifice usability for security which can be bypassed anyway
(privilege escalation)?
If the services are not locked down to just the files and folders they
need access to (and with respective permissions), then the attacker
gains full control over your server.
And one last thing - if I locked sshd down (I'm not sure whether your
example is a locked down sshd or a standard one), I wouldn't let it
access everyone's files ;)
Precisely what? What's defined in POSIX ACLs wouldn't apply well to
processes anyway since they were designed for file access. SELinux was
created to deal with what you're talking about, why not use it?
Because SELinux is too complicated to be used effectively by most system
administrators - that's why.
Alan Cox wrote:
That was a while ago, oh way back in 2002. Update to a modern
distribution and a file system that supports ACLs and you'll get ACLs
and depending on the distro also SELinux.
But the POSIX ACLs aren't really flexible enough - hence the reason that they have not received the popularity and widespread usage they supposedly deserve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
