On Wed, 2010-04-28 at 14:31 -0400, Karl MacMillan wrote: > 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. Dan's use model appears to be enabling unconfined users to assume roles via sudo for things like web administration. So you sudo -r webadm_r, becoming both uid 0 and webadm_r:webadm_t, and then you can go change /var/www at will, including setting DAC modes via chmod but are otherwise restricted based on webadm_t. But he doesn't want you to be able to leave an entrypoint executable into uid 0 in /var/www that can later be executed from unconfined_t. I'm not so fond of the scenario. But I can understand wanting to control the ability to create new entrypoints to uids/gids, and I don't mind splitting up setattr further as long as we come up with something rational and don't keep adding ad-hoc permissions every so often. So I want to identify now all the possible permissions of interest, as I mentioned in my email last Friday. And I want to fix an existing problem we have with the utimes(NULL) and truncate() checking while we're at it. I won't ack new setattr permissions until we've fixed that. -- 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.
