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?)
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?)