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
