Will these ever be implemented? If so, when? At the moment, all the
Linux kernel brings (ie. without any external access control systems
such as grsecurity or RSBAC) are rwx permissions. Even Windows brings
more finely-grained access controls than this - is that something we
want to live with?
I for one would like to see more finely-grained access controls
available out-of-the-box, so to speak. I don't want to have to download
an LSM plugin or whatnot in order to do it for me. Does it really matter
which one you choose? Pick the most mature one and be done with it. If
you choose grsecurity and some RSBAC die-hards still want to use RSBAC,
let them - but at least have _something_ in the kernel which allows more
finely-grained controls than rwx.
Adieu.
Brian Beattie wrote:
> Having implemented ACLs twice on Unix and Unix-like systems, I don't see
> what the fetish some people have for them. Frankly juts about anything
> you can do with ACLs (and anything you should want to do) you can do
> with users/groups and the standard Unix/Linux permissions. Why add
> unneeded cruft to the kernel.
Because instead of having an all-powerful account (which we so lovingly
know as root), you can separate specific roles to different accounts. To
use Windows' ACLs as an example:
- Adjust memory quotas for a process
- Allow/deny access to this computer from the network
- Backup files and directories
- Bypass traverse checking
- Change system time
- Increase scheduling priority
- Load and unload device drivers
- Manage auditing and security logs
- Restore files and directories
- Shutdown the system
- Take ownership of files or other objects
As you can see, those are finely-grained controls. Why would these be
useful on Linux? Because you can have a root account which can bind
Apache to a port <1024, and even if it is compromised it cannot
"shutdown the system," or "deny access to this computer from the
network," thus the attacker will be able to cause minimal damage. Yes,
the same can be done on Linux using SELinux, AppArmor, or some other ACL
system, but again - those aren't part of the kernel. They are extra
apps, and adding layers is not always the best solution when it comes to
security.
> I know that some spooks think you have to
> have ACLs to have a trusted system, but these are the same people who
> think you need to violate my freedoms to protect them.
>
Um.. Forgive me for a second, but are you suggesting that a Linux system
running a service(s) under full root privileges (such as Apache) is just
as secure as a Linux system running the same process but with
compartmentalisation to make sure that each service has access to just
the files and directories it needs, achieved (currently) via AppArmor,
SELinux, or a similar ACL system? If you really do think that, you may
want to read a few more papers and/or books. If Apache is bound to port
80 as root and is not restricted (via ACLs) to just the directories,
files, libraries and whatnot that it needs access to, and it is
compromised, then the attacker has full control over your server. If you
have ACLs in place, the attacker can only access the files that Apache
has access to, thus protecting all other files on the server (and thus
greatly decreasing the chances of the attacker implementing a
hard-to-detect kernel rootkit, or some other malware).
On Aug 04, 2006, at 18:52:41, RazorBlu wrote:
> Because instead of having an all-powerful account (which we so
> lovingly know as root), you can separate specific roles to
> different accounts. To use Windows' ACLs as an example:
>
> - Adjust memory quotas for a process
> - Allow/deny access to this computer from the network
> - Backup files and directories
> - Bypass traverse checking
> - Change system time
> - Increase scheduling priority
> - Load and unload device drivers
> - Manage auditing and security logs
> - Restore files and directories
> - Shutdown the system
> - Take ownership of files or other objects
This is _exactly_ what SELinux does for you. You can break down
permissions on very nearly a per-syscall basis (not quite, for
efficiency reasons, but pretty damn close).
> As you can see, those are finely-grained controls. Why would these
> be useful on Linux? Because you can have a root account which can
> bind Apache to a port <1024, and even if it is compromised it
> cannot "shutdown the system," or "deny access to this computer from
> the network," thus the attacker will be able to cause minimal
> damage. Yes, the same can be done on Linux using SELinux, AppArmor,
> or some other ACL system, but again - those aren't part of the
> kernel. They are extra apps, and adding layers is not always the
> best solution when it comes to security.
You're quite wrong about SELinux; it _is_ part of the kernel.
Admittedly it requires a policy to be built and loaded from
userspace, but your "ACLs" would require some ACL utilities to apply
those from userspace. In any case SELinux is an extremely powerful
model; you can define your arbitrary RBAC+TE state machine and
constraints, then the kernel applies it to your system; as simple (or
horribly complicated, as the case may be) as that.
> Um.. Forgive me for a second, but are you suggesting that a Linux
> system running a service(s) under full root privileges (such as
> Apache) is just as secure as a Linux system running the same
> process but with compartmentalisation to make sure that each
> service has access to just the files and directories it needs,
> achieved (currently) via AppArmor, SELinux, or a similar ACL system?
Here's a better security model: SELinux lets you give root access to
everybody and still have a 100% secure system (although it's not
really recommended). Google around for the public SSH-accessible
SELinux testbeds with root's password set to "password" or "1234" or
whatever and feel free to log in and have a look. Besides, we do
have POSIX ACLs on files; if that's what you're looking for, but
that's not extensible enough to cover processes too.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> You're quite wrong about SELinux; it _is_ part of the kernel.
> Admittedly it requires a policy to be built and loaded from userspace,
> but your "ACLs" would require some ACL utilities to apply those from
> userspace.
That is true, but is it included in every stable release of the kernel
(by default)? And why aren't more distributions using it (the popular
ones - for example, I know Mandriva uses grsecurity).
> In any case SELinux is an extremely powerful model; you can define
> your arbitrary RBAC+TE state machine and constraints, then the kernel
> applies it to your system; as simple (or horribly complicated, as the
> case may be) as that.
And what are your feelings on SELinux still being "under research"? Can
such a system be used in a production environment, when it has not been
declared a completely mature system by its creators?
> Here's a better security model: SELinux lets you give root access to
> everybody and still have a 100% secure system (although it's not
> really recommended). Google around for the public SSH-accessible
> SELinux testbeds with root's password set to "password" or "1234" or
> whatever and feel free to log in and have a look. Besides, we do have
> POSIX ACLs on files; if that's what you're looking for, but that's not
> extensible enough to cover processes too.
A 100% secure system except for the files that sshd has access to,
correct? If global access is allowed to root, but it is locked down to
sshd, then anyone who logs in as root can only modify those files that
sshd has access to... Or is there a part of the puzzle that I am
missing? I had not heard of those testbeds before, but I would like to
see how they are set up.
"Besides, we do have POSIX ACLs on files; if that's what you're looking
for, but that's not extensible enough to cover processes too." - Precisely.
> Cheers,
> Kyle Moffett
>
Regards,
RazorBlu
On 08/05/06 01:54:48AM +0200, RazorBlu wrote:
> Kyle Moffett wrote:
> >You're quite wrong about SELinux; it _is_ part of the kernel.
> >Admittedly it requires a policy to be built and loaded from userspace,
> >but your "ACLs" would require some ACL utilities to apply those from
> >userspace.
> That is true, but is it included in every stable release of the kernel
> (by default)? And why aren't more distributions using it (the popular
> ones - for example, I know Mandriva uses grsecurity).
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.
> >In any case SELinux is an extremely powerful model; you can define
> >your arbitrary RBAC+TE state machine and constraints, then the kernel
> >applies it to your system; as simple (or horribly complicated, as the
> >case may be) as that.
> And what are your feelings on SELinux still being "under research"? Can
> such a system be used in a production environment, when it has not been
> declared a completely mature system by its creators?
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.
> >Here's a better security model: SELinux lets you give root access to
> >everybody and still have a 100% secure system (although it's not
> >really recommended). Google around for the public SSH-accessible
> >SELinux testbeds with root's password set to "password" or "1234" or
> >whatever and feel free to log in and have a look. Besides, we do have
> >POSIX ACLs on files; if that's what you're looking for, but that's not
> >extensible enough to cover processes too.
> A 100% secure system except for the files that sshd has access to,
> correct? If global access is allowed to root, but it is locked down to
> sshd, then anyone who logs in as root can only modify those files that
> sshd has access to... Or is there a part of the puzzle that I am
> missing? I had not heard of those testbeds before, but I would like to
> see how they are set up.
>
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.
> "Besides, we do have POSIX ACLs on files; if that's what you're looking
> for, but that's not extensible enough to cover processes too." - Precisely.
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?
Jim.
Ar Gwe, 2006-08-04 am 23:42 +0200, ysgrifennodd RazorBlu:
> Will these ever be implemented? If so, when?
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.
Alan
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.
On Saturday 05 August 2006 20:03, RazorBlu wrote:
[snip]
> > 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.
First you didn't RTFM, and moaned about how superior Windows NT was to Linux,
now you've been given multiple (superior) solutions, you're moaning that
they're too complicated?
Please, complain on SELinux mailing lists, don't pollute LKML any further.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 08/05/06 09:03:36PM +0200, RazorBlu wrote:
> 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?)
AppArmor isn't more advanced and it's not been merged with main yet because
a lot of people feel it's the wrong way to attack the problem. AppArmor
uses path names to decide what's good and bad and paths aren't absolute,
they can change under you without warning, multiple paths can point to the
same file, etc.
> 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?
I don't know that AppArmor is being used by more people, infact I had never
even heard of it until the thread on lkml a little while back. And SELinux
is enabled by default in FC5 now so only those people who explicitly turned
it off aren't using it.
> 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)?
>
But part of the point of having a good RBAC setup is that root doesn't have
any real rights and each daemon runs in their own domain. So if you break
sshd you still don't have any real access.
> 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.
>
That's true no matter what.
> 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.
>
So don't be like most administrators, take the next step and learn to use
SELinux.
> 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.
>
No, it's that most people don't really need POSIX ACLs since most cases can be
taken care of with normal unix permissions.
Jim.
Ar Sad, 2006-08-05 am 21:03 +0200, ysgrifennodd RazorBlu:
> 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,
It depends what you are trying to achieve.
> 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?)
I think the consensus if anything was more to adding AppArmor once it is
cleaned up than not. Its far more primitive than SELinux and has a very
basic security model but it can be easier to configure some basic setups
with it which makes it useful to some people
The LSM means the kernel doesn't have to have an opinion any more than
it has to define your choice of file system.
> Because SELinux is too complicated to be used effectively by most system
> administrators - that's why.
Thats why vendors ship policies. Firewalling has the same problem.
Alan