On Wed, Apr 28, 2010 at 2:07 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > 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. > Ok - thanks for the explanation. You make it sound almost as if DAC is discretionary. Next stupid question then - is disallowing setattr for these shells either not sufficient to achieve the desired security or not workable in practice? I know the goal is to allow chmod but just not allow creation of root owned setuid files, but is allowing chmod really necessary for these limited use shells? Again, I'm just trying to avoid the slippery slope of adding fine-grained control over DAC to SELinux. Karl > -- > 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.
