On Fri, 2008-01-11 at 09:37 -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stefan Schulze Frielinghaus wrote: > > 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 ...). > > > Well this is actually what I would like to avoid. I would prefer one > domain that allows the administrator to admin both the httpd and mailman > > I am adding to Fedora policy admin interfaces so you can easily creat an > administrator policy that looks something like. > > userdom_base_user_template(myadm) > apache_admin(myadm_t) > mailman_admin(myadm_t) > mysql_admin(myadm_t) > gen_require(` > type staff_t; > ') > allow staff_t webadm_t:process transition; You don't want staff_t to directly transition to webadm_t. It should have to go through an intermediary, like newrole_t or sudo_t. > > You load this policy module and create a staff user with the myadm_r, > and now use sudo to get a shell that can manage mysql, mailman, and > apache. The user then does not need to think about, I am administrating > the apache so I need to execute some bizare commands to become root, and > then later that shell is no good for managing mailman or mysql. > > > >>>> 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 ;-) > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkeHf0IACgkQrlYvE4MpobP+ngCeIRm8RXbGvfFcidWMB8g0kZDG > dKIAn1/aiMefqyzoeUhQQOvGrBtwXS4T > =oljc > -----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. -- 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.
