ACLs

ACLs

[RazorBlu]

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.

Re: ACLs

[RazorBlu]

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).

Re: ACLs

[Kyle Moffett]

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

Re: ACLs

[RazorBlu]

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

Re: ACLs

[Jim Crilly]

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.

Re: ACLs

[RazorBlu]

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.

Re: ACLs

[Alistair John Strachan]

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.

Re: ACLs

[Jim Crilly]

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.

Re: ACLs

[Alan Cox]

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

Re: ACLs

[Alan Cox]

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

ACLs

[Lukas Hejtmanek]

Hello,

I use nfs4-acl-tools-0.3.3 and I get some oddities when setting the ACL:

$ nfs4_getfacl test
A::OWNER@:rwatTcCy
A::xhejtman@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
$ nfs4_setfacl -s "A::ludek@META:R" test
$ nfs4_getfacl test
D::OWNER@:r
A::OWNER@:tTcCy
A::ludek@META:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy

is this something expected or buggy acl-tools?

-- 
Lukáš Hejtmánek

Re: ACLs

[J. Bruce Fields]

On Thu, Aug 05, 2010 at 02:47:29PM +0200, Lukas Hejtmanek wrote:
> Hello,
> 
> I use nfs4-acl-tools-0.3.3 and I get some oddities when setting the ACL:
> 
> $ nfs4_getfacl test
> A::OWNER@:rwatTcCy
> A::xhejtman@META:rtcy
> A::GROUP@:tcy
> A::EVERYONE@:tcy
> $ nfs4_setfacl -s "A::ludek@META:R" test
> $ nfs4_getfacl test
> D::OWNER@:r
> A::OWNER@:tTcCy
> A::ludek@META:rtcy
> A::GROUP@:tcy
> A::EVERYONE@:tcy
> 
> is this something expected or buggy acl-tools?

NFSv4 ACLs deny by default.  Thus the ACL "A::ludek@META:R" denies
permission to everyone else--including the owner of the file, if the
owner is not ludek.

The linux server has no way to store in its filesystem an acl that says
that; it *always* checks permissions for the owner before checking any
user permissions.

So the server decides it's safer to be pessimistic and adds that first
DENY....

Arguably the server could be less paranoid here.  But we'll always have
oddities like this as long as it doesn't have NFSv4 ACLs to work with on
the exported filesystem.  (Somebody's working on that.)

Workaround for now is probably just to always set the OWNER permissions
to be at least as permisive as anyone else's.  Or just add the
"A::ludek@META:R" ace instead of replacing the ACL wholesale (which is
what "-s" does).

(And then you'll still get ONWER, GROUP, and EVERYONE ACEs added on, but
they won't be as silly.)

--b.