On Wed, 2010-04-28 at 13:57 -0400, Karl MacMillan wrote: > On Wed, Apr 28, 2010 at 11:39 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > >>> This is not default allow. It is DAC + MAC as opposed to the way most > >>> people run, which is just DAC. I am trying to make setattr check better. > >>> > >>> DAC + sudo versus DAC + MAC + SUDO. > >> > >> I thought that the intent of the current MAC / DAC interaction was > >> that capabilities are used to decompose root and MAC can restrict > >> capabilities on processes to add extra DAC protections. Now, I'll > >> admit a good deal of ignorance here, but is there a reason that we > >> can't just write policy using that mechanism to accomplish what you > >> are after? If we prevented confined admin domains with root from > >> having the needed capability to setuid files isn't that enough? Or if > >> the right capability doesn't exist, can't you add a new capability? > >> > >> Karl > > Write now the ability to setattr on a file gives you the ability to > > chmod 4755 EXE on types you control. > > > > But we want to allow chmod 755 EXE but prevent chmod 4755. Eric is > > adding a Access check for this. > > I understand that, but I (and I think others) are concerned about > directly adding permissions for what is essentially DAC policy. I was > wondering why the current strategy of mitigating DAC with SELinux > through capabilities is not workable in this case. That has the > additional benefit of allowing non-SELinux systems to benefit as well > if new capabilities are needed. Setting the suid bit on a file is not a privileged operation on Unix/Linux, so there is no capability check on it and you can't add a capability check to it without breaking Unix/Linux compatibility. Any user is free to create his own "entrypoints" to his own uid/gid in this manner at present. Dan wants to be able to prevent that, particularly since he is trying to give a non-root user the ability to run confined root shells. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
