Re: ACLs

From: RazorBlu
Date: Sat Aug 05 2006 - 15:10:24 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/