On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephen Smalley wrote: > > On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote: > >> Daniel J Walsh wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> I have a working demonstration of My version of RBAC in Rawhide/FC8. > >>> In my view of the world, users have two roles. User Role and Admin > >>> Role. > >>> > >>> So I might login as a staff_t user and be able to transition to > >>> webadm_r:webadm_r. > >>> > >>> In Rawhide right now staff_t can only run sudo to become root. > >>> Staff_t is not allowed to execute su. staff_t users should not know > >>> the root password. I have hacked up a script /usr/bin/webadm which > >>> executes newrole -r webadm_r -t webadm_t and newrole's pam has > >>> pam_rootok. > >>> > >>> Now I edit the /etc/sudoers and allow > >>> > >>> dwalsh ALL=(ALL) /usr/bin/webadm > >>> > >>> This allows me to use sudo to become webadm_t as root. (Policy > >>> obviously has to be correct. But this is very cumbersome for the > >>> administrator and does not scale. > >>> > >>> I think we need to add SELinux support to sudo, so the administrator > >>> could easily add something to /etc/sodoers like > >>> > >>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh > >>> > >>> then sudo would execute the code that newrole does to very the > >>> transition and > >>> > >>> setexeccon(dwalsh:webadm_t:webadm_t) > >>> exec(/bin/sh) > >>> > >>> I was told that you are the upstream maintainer of sudo, so I wanted > >>> your input/help on making sudo selinux aware. > >> I suppose it depends on what you really want to be able to do. Do you > >> > >> a) wish to be able to run arbitrary commands via sudo but be able to > >> specify a role and type ala newrole via -r and -t flags? > >> > >> or > >> > >> b) want to be able to force a command run by sudo to use a role and type > >> that is specified in the sudoers file? > >> > I don't want the user to even know about webadm_r:webadm_t or care. He > will just know that when he is UID 0 he can only use certain directories. > > Allowing someone to specfify > > sudo -r webadm_r -t webadmin_t /bin/sh > > Is not important. > > Having them say > > sudo /bin/sh > > and ending up with staff_u:webadm_r:webadm_t is important. The idea with specifying the role and type at the sudo level is quiet good and important I think. Just imagine a scenario where you have one admin who takes care about the web-server and email-server. So you would have a webadmin_t and mailadmin_t type. If the admin wants to execute something like "sudo vim" (e.g. to change the config files) he would only have on role/type e.g. the webadmin_t but could _not_ change to mailadmin_t. You could easily fix this while creating a secondary Linux user to get around this but I think this wouldn't be nice and could possibly end up with dozens/hundreds/... of Linux user accounts (which are hard to manage, keep clean and isn't user friendly ...). > > >> Doing a) is probably easier than b) though the two are not mutually > >> exclusive. > > > > Didn't we used to have a) in Fedora (before Fedora 5, IIRC)? And didn't > > it suffer from a number of problems? Have to go back to the > > fedora-selinux archives and/or bugzillas to recapture the history there. > > > > Also, while integration with sudo might be useful, it seems more > > pressing to integrate with policykit given its increasing adoption by > > distributions, right? > > > No sudo and policykit serve two different problems. I am looking for > sudo as a tool for use by actual administrators. You need to get > something configured as the root user. Currently you use su to do this. > And give out the root password. With SELinux we can confine the user to > the particular files/processes that they can effect while running as the > root user. The beauty of using SELinux in this manner is I can allow > the administrator to configure the system with tools like > vi/emacs/grep/cat/sed ... While controlling which files he can modify > and which processes he can transition to (initscripts). > > policykit needs policy to confine apps that are doing things on behalf > of the user. So the user wants to change the clock. Some how the user > authenticates himself the PolicyKit and the PolicyKit/Dbus executes > commands as root on behalf of the user. The big caviat here is that we > need to make sure the tools ONLY do the things for the user that they > are defined to do. So if the user is allowed to change the Time on his > machine, the script that runs on his behalf had better only be able to > change the time. > > Whether or not SELinux gets involved in the authorization is up for debate. I would really appreciate something like this. It makes it very easy to allow only certain people to access/admin the stuff they need to. It is always good to know that an webserver-admin can only damage the webserver and not the whole system ;-) -- 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.
