-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/28/2010 02:31 PM, 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. > > Karl My use case was of the web administrator creating cgi scripts. Being able to copy files into a directory and then chown and chmod would be the use case. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvYgWoACgkQrlYvE4MpobOzTACfWUOhYXlms/NIaeLQJfEpkQIq m6cAoJNCJCb55Xkt/nW85A5CeXdhKB5R =j1PM -----END PGP SIGNATURE----- -- 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.
