Categories
DSSP2

Idea for alternate way of dealing with users

I am still working on documenting DSSP3. It is a struggle. I now have 8 chapters done, and I estimate another 8 to go. This post is not about that. Instead I wanted to write about this idea I had about redesigning policy for user login shells.

In DSSP2 every class of login user, actually i suppose every class of user period, has a private shell type. This complicates things but it also allows me to associate rules with individual shell types. Ive been playing with the idea of giving all logins except root the same login shell type, and then to leverage roles to govern what domains can be transitioned to using RBAC roletype rules. So user A and B can run app1 with a domain transtiion to app1_t because they both have the same shell type but user A’s role is not allowed to associate with app1_t and so user A is not able to run app1 with a domain transition because the persons role is not authorized. Thinks for example access to sudo and other setuid apps.

But root logins and root shells? You know root shouldnt be able to log in directly in the first place except for emergency shells and maybe local logins. But root shell policy certainly doesnt have to be the same as unpriv users shell policy. Some people in Fedora log in with staff_u:staff_r:staff_t and then run a root shell with staff_u:unconfined_r:unconfined_t instead of staff_u:sysadm_r:sysadm_t. I think this might be worth considering. I mean If you only log in as root from an emergency shell, and if you only access a root shell from sudo then it might not be so bad to give root shells unconfined access this way. You still log in with a confined shell. So you can just say, Joe can run sudo because joe’s role is authorized with sudo type, and joe’s role can be transitioned to some unconfined root shell role..

The root shell role does not have to be fully unconfined though. It can be some derivative that is unconfined minus somethingsomething like access to sec and auth files. Those can still only be access via vipw and visudo , semodule , auditctl etc etc. This design would greatly simplify policy and it would leverage/rely on RBAC more instead. Confined administration wouldnt be affected as those accounts still can have private types because those accounts shouldnt be used to run programs that need special access and then need to be able to access shells on behalf of calling users. They just need to be able to run systemctl, kill, maybe strace, a simple editor like vi or nano etc.

But yes root logins and shells would be unconfined or close to generic administration. So one needs to be careful not to allow root logins from the network, or rely on other means to secure that aspect. Its a bitter pill to swallow but it might be worth pursuing. I wonder how much can be saved in terms of rules,types and policy footprint in general etc. Its just a different approach. Different trade offs but its not like i am throwing everything over the fence..

I still have time to let this model sink in since it is going to take me atleast another week to complete a 0.1 version of the dssp3 docs, and as I have mentioned earlier I haven’t quite decided yet on whether I want to build a new personal policy on top of the currently iteration of DSSP3. It seems likely though because even though some aspects of DSSP3 do not quite sit well with me, I haven’t been able to come up with any better alternatives yet and I cannot dwell on it forever either so at some point I am going to have to accept a path forward.

1 reply on “Idea for alternate way of dealing with users”

Oh and BTW, this way I can also treat /root as a totally separate directory with a private type, so that it cannot be accessed from other shells from a TE perspective.

Leave a Reply

Your email address will not be published. Required fields are marked *