On Sun, Jul 20, 2014 at 04:28:58PM +0400, Jason Zaman wrote:
> > Role segregation
> > ================
> >
> > Which roles to make available?
> > ------------------------------
> >
> > 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.
>
> The ones that are in refpolicy are probably not hard to support. The issue is
> more of what type of machine it is. My things are all mostly personal machines
> so I dont want to have 10 different accounts and keep changing between for
> single commands. For companies tho I can definitely see them using all the
> roles for different people in the company. Currently if people want to use all
> of them they will need a lot of work because we dont provide much for it.
>
> Do we happen to have any information about big installations that use
> gentoo and selinux and what their use-cases are?
I asked around some time ago on the G+ community but didn't get much
feedback. What I know professionally is (not counting the "all our users are
unconfined_t" deployments) that most struggle with the users conceptually,
because they don't have a clear definition to fall back on.
Most deployments tend to follow the distribution choice, or customize. The
ones that customize we don't really need to cater much for (beyond to make
sure that these customizations aren't broken), and the ones that follow the
distribution should have a clear, well-documented approach on things.
Considering work-load, our user base, etc. I think the best way forward is
to support a bit more roles, but also make sure that their purpose remains
focused: auditadm_r, logadm_r, secadm_r, dbadm_r, webadm_r, guest_r,
xguest_r.
For those that aren't refpolicy-supported, I think they are useful for
various reasons:
- dbadm_r and webadm_r are two "example" user domains which serve a
particular administrative purpose. It can be used by others to learn how
to manage administrative user domains. The focus on databases (dbadm_r)
and web services (webadm_r) is that these are the two most popular
middleware services around which can be easily tested.
- guest_r and xguest_r would provide a very limited ("empty") user domain
for users with basic privileges. I would like to support these (using this
principle) as they are also available in RHEL and Fedora.
Because of these four additional domains, we can have
- staff_r and user_r similar (i.e. keep them in sync, except for the ability
to use sudo/su and roleswitching which is only available for staff_r) as
users who want a more "closed-down" user domain can either enhance the
xguest_r role, or copy and make their own implementation
- sysadm_r be a full-administrative domain, as users can then look at
dbadm_r and webadm_r to see how to make more "closed-down" administrator
domains
> > Differentiation between staff_r and user_r?
> > -------------------------------------------
> >
> > 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
>
> I personally use staff_r as my main account and do not use user_r at all
> so I just end up having an extra policy which enables things that are
> in user but not staff (wine, dropbox etc) on my laptop. Im not sure what
> the right way to do things for this is. I think having most of the
> things the same in staff/user is not that big of a deal since if you
> dont have sec-policy/selinux-dropbox installed, the optional() block
> just disappears. Although if someone can install packages then it
> suddenly gets enabled but I think at that point it is already game over.
The point is more about the applications that still run in the user domain
rather than their own domain. Vulnerabilities in firefox (mozilla_t)
shouldn't be able to impact the system much beyond what mozilla_t can do
(and with our own support for XDG directories, even user content can be
properly protected), but applications that /do/ run in the user domain might
have more impact to the system if they run in staff_t, as they can "try" to
elevate their privileges (depending on the system configuration, this might
be possible) whereas user_t wouldn't allow that much.
But given the user domains above, having staff_t and user_t be very similar
and keep on focusing on confining the user applications, I think we are
taking a safe route here. The worst risks aren't within the domains, but in
the applications that would still run in the user domains.
> > Init script support
> > ===================
> >
> > Transparent full system administration?
> > ---------------------------------------
> >
> > So not this: ~# run_init rc-service nfs start
> > But this: ~# rc-service nfs start
>
> This is sort of annoying honestly, Im in favour of removing run_init in
> front and make it just happen automatically. That said, I do like that
> it can authenticate (I like it on my server since I dont restart things
> much but dislike it on my laptop where I have less running and start
> them manually when I need them. I think we should integrate this into
> openrc directly but ideally i'd like to be able to keep the pam
> authentication parts of it so that people can choose if they want to
> type the password or not.
>
> I also saw someone having issues with puppet or one of those cuz it just
> ran the script and adding run_init in front was complicated.
Indeed. I think we should definitely remove the need for calling run_init
directly in any case.
> > sysadm_r for System operational administration only?
> > ----------------------------------------------------
>
> This seems like it would be a big hurdle for most new (and old?) users.
> If we enable more of the roles from above then perhaps there can be some
> roles that are disallowed it but I think changing the current behavior
> is a little strange.
Ok, I can live with that. And indeed, if we were to remove lots of
privileges from sysadm_r users would be severely impacted.
I'll see if the system operational code and "the rest" can be properly
documented in the policy files instead, so that /if/ someone would like to
instantiate a system operational role (like sysoper_r) they can copy the
sysadm_r information and remove the non-critical stuff themselves.
> > Follow the Gentoo-is-about-choice paradigm and support both through USE?
> > ------------------------------------------------------------------------
>
> There is currently a use-flag for unconfined, making similar useflags
> (or a use_expand?) for how the roles should be used sounds like the
> easiest way. If people install with the defaults they get staff/sysadm
> like exist currently but if they enable some of the other roles then
> maybe sysadm would lose some of its privs to that other role. (eg enable
> secadm and sysadm is no longer able to change the policy)
I think maintaining an expanded USE flag would become a maintenance burden,
but I'm not saying "no" here. We can do this in a second phase if the
sysadm_r role can be properly documented (cfr. paragraphs above) as we can
then include the proper ifdef() statements.
The reason I'm not in favor of taking this up right now is that we need to
support this throughout the future as well, and I don't know how to do this
with CIL in the future. Not saying it won't be possible though, just
something we might want to implement later.
> > Disadvantages: implementation possibilities are reduced (but hey, what do
> > you care, right?)
>
> How are they reduced? You mean ways to implement the policy or ways to
> use it as a user? How much more complicated would this become for the
> policy?
Policy-wise. The discussion was about the run_init support. We can make
sysadm_r support everything without needing run_init and without needing to
"integrate" run_init in OpenRC (or other init systems) by plain policy
rules.
However, the moment we make this optional, or at least user-defined through
USE flags, then the implementations must focus on at least two things:
run_init support in OpenRC (with the ability to discern calling run_init
based on USE flag settings, or based on interrogating the SELinux policy to
see if it is wanted) and policy.
Basically, if we integrate run_init in OpenRC, how do we make sure it
doesn't call it when it shouldn't (user domain has no run_init_t privileges,
but transitions to sysadm_r/initrc_t directly)?
If sysadm_r is "system operational only", then OpenRC shouldn't call
run_init except for the init scripts that are initrc_exec_t (and not say
tor_initrc_exec_t), and also not if the policy has direct_sysadm support.
But considering the ideas above, having sysadm_t be an all-encompassing
administrative domain, we only need to have OpenRC call run_init if the user
domain is sysadm_t. Other domains can be made to transition when needed
policy-wise. I think. I still need to get my head around it ;-)
I'll document the idea on the wiki (somewhere in the Project:SELinux
namespace) and expand on it some more to see if we don't have any loose
strings.
Thanks for the feedback!
