Re: [gentoo-hardened] SELinux support principles discussion

[Jason Zaman]

On Tue, Jul 15, 2014 at 06:02:32PM +0000, Sven Vermeulen wrote:
> jump into the proper changes (together with perfinion and other developers),
^.^

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

> 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.

> 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.

> 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.

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

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

-- Jason