Hi guys As I'm preparing for my yearly vacation, I would like to initiate a quick poll (or discussion) regarding a principle that I'd like to finish up with.
As some of you are aware, I'm a big proponent for principles in development. For SELinux, a high-level principle document is available at https://wiki.gentoo.org/wiki/Project:SELinux/Development_policy but after my holidays I want to document this further. Whenever a decision needs to be made with respect to SELinux policies, I try to use the principles documented there to make the choice. But I'm not going to ask right now for rewrites on the documentation, but to focus on some decisions that we should do right now in order to give our policy a good "general direction" sense. I hope to get some good feedback on this, so that after my holidays I can jump into the proper changes (together with perfinion and other developers), as we have a lot of work to work through this year ;-) Role segregation ================ Right now, our policy only provides a limited set of roles: sysadm_r (for system administration tasks), staff_r and user_r (for regular user activities, where staff_r is the only one allowed to switch to other roles as well). And of course "unconfined_r" for only very lightly-restricted domains. Which roles to make available? ------------------------------ Do we want to include more roles in our policy? "Popular" roles are: auditadm_r :: Audit administration Used for a highly privileged, but generally read-only administration role. Meant not just to "manage audit logs", but instead to grant to IT Auditors that want to take a look on the system without granting them any change privileges (except for managing the audit logs apparently). This one is available through refpolicy logadm_r :: Log administration Used for managing system logging. This one is available through refpolicy secadm_r :: Security administration Used for managing the SELinux policy. If used, the question that follows is if sysadm_r should still be allowed to manage the SELinux policy as well (if not, this will be a challenge to implement, but not impossible) This one is available through refpolicy dbadm_r :: Database administration Used for database administrators This one is not available through refpolicy webadm_r :: Web (Application/Server) administration Used for web administrators (Apache, nginx, Tomcat, ...) This one is not available through refpolicy guest_r :: More restricted role than user_r Used to grant a minimum set of privileges, requiring the (security) administrator to grant specific application privileges. If used, then we would grant most/all application privileges to the staff_r and user_r as "counter-example" role This one is not available through refpolicy xguest_r :: Like guest_r, but with X11 support Used for implementations such as Kiosk mode, requiring the (security) administrator to grant specific application privileges. This one is not available through refpolicy My opinion: I don't mind to support them all (i.e. document the use and the principles behind them and making these roles available through the base policy). I have most of them (except logadm_r) running on all my production systems anyway so I might as well support them through Gentoo Linux. Differentiation between staff_r and user_r? ------------------------------------------- The staff_r is meant as the "unprivileged" role for the administrator, whereas user_r is meant for the "unprivileged" role for users with no specific role(s) assigned otherwise. This would mean that staff_r == user_r, but with newrole_t (and other role switching domains) support. Depending on the outcome of the previous question, there are two approaches to take between staff_r and user_r: 1. Have staff_r and user_r remain "in sync" with just the newrole_t difference, or 2. Only support "less risky" domains in staff_r and reduce user domain privileges The idea behind option (2.) is that many users will have their daily tasks run as staff_r, and perhaps enable password-less role switching. If application vulnerabilities would result in account hijacking on staff_r, then these might jeopardise the system. To counter-act this, we could only grant well restricted application domains to staff_r (those that are needed for administrators to do their "unprivileged" jobs), such as running browsers and so, but not to (just to name something) run rtorrent (personally, I wouldn't like my admins to run rtorrent through their administrative account, even in an unprivileged role). The problem with (2.) however is to decide what to allow on staff_r and what not. Something to think about. Init script support =================== Transparent full system administration? --------------------------------------- Do we want the sysadm_r role (by default assigned to system administrators) to be able to run all possible init scripts on the system (/etc/init.d/*) without requiring the user to prepend the commands with "run_init"? So not this: ~# run_init rc-service nfs start But this: ~# rc-service nfs start If so, then we can either make sure that sysadm_t is always allowed to do this policy-wise (which might be as simple as enabling the DIRECT_INITRC option in the build), or through the integrated run_init support of OpenRC. The base premise however is to set this as a principle, so that we know what to aim for (and let us decide on the "how"). Advantages: works out-of-the-box, "system administration role" is a somewhat fully privileged role which is what many users expect. Disadvantages: no strict role separation (users who want more role separation will need to create their own roles) sysadm_r for System operational administration only? ---------------------------------------------------- If not then perhaps we want to allow sysadm_r to manage true system operational services (those needed to boot the system) but not those that are "hosted on" the system. So the NFS service might not be assigned to the sysadm_r role by default (okay, this is debatable - take tor then as an example), whereas sysctl is. Users that want to extend the privileges of sysadm_r will always be allowed to, but this does mean that "run_init" would not be allowed anymore for the sysadm_r role (as run_init in its current form allows the user to invoke any service). If this is selected, then we'll improve our documentation to inform users how to assign additional privileges to the sysadm_r role (for those that want to manage their system fully) while staying quite strict in the default policy. Advantages: minimal privileges, users tweak the system further to the extend they want Disadvantages: new users will notice things don't work out-of-the-box Follow the Gentoo-is-about-choice paradigm and support both through USE? ------------------------------------------------------------------------ We can implement a situation where we focus on the strict implementation, but where users can build the policy differently using a USE flag that enables the other support as well. I don't think we can do it with a SELinux boolean (due to limitations of what can be within a conditional statement) though. Advantages: best of both worlds Disadvantages: implementation possibilities are reduced (but hey, what do you care, right?)
