On Fri, 2008-01-11 at 10:32 -0500, Stephen Smalley wrote: > 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. Also, how are you handling the tty/pty and fd relationships (usually addressed by newrole by relabeling the tty/pty and re-opening the fds into its own type)? That was a major problem with the old sudo selinux patch. > > > > 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.
