Categories
DSSP2

DSSP3 status update

I am almost done sketching the outlines of DSSP3. I need some time to audit the things i did though. Today when perusing some of the functionality I hit an issue with name-based type transitions. Might be a bug. Sure looks like it. So yes bummer but the show must go on. So i have the basic system domain ready. Just need to start targeting more and more system services. I did a few so far just enough to get the system to boot in enforcing mode and with some basic stuff address properly. Networkd, Resolved, Logind, Login, Getty, SSH server and a few more, also chkpwd and updpwd as that is used by PAM. System logins are allowed by default, but can be disabled with the login.sys_login and ssh.daemon.sys_login booleans respectively. There is an unpriv user account user.id, and one with sudo access to the system accound wheel.id. All unpriv users share the same login shell permissions with one exception: role access. The wheel.role may associate with sudo.subj, where the user.role may not. Ive revisited my RBACSEP and man it gets complicated really quick. Roles need to be allowed to associate with types, but the idea was that I did not want to give roles a carte blanche to just go and associate with all object types (I did that in DSSP2 and it makes thinks a lot easier) So now I am constantly identifying system objects that users need be able to create objects on. Examples are extended attribute file systems in general. Then theres the constraints. RBACSEP constrained roles arent allowed to write to system files unless explicity told otherwise. They can read all for a RBACSEP perspective, just no write operations. Exceptions are: /dev/tty, /dev/zero, various sock files (dbus for example), but also selinuxfs files (yes selinuxfs has files that are widely writable)

The RBACSEP implementation is very expensive in DSSP3 and now I remember why I decided to cut some corners there in DSSP2. There were quit a few deju vu moments for me so far. The next step is to address confined privileged roles, and then its just a matter of “porting” stuff. Eventually I will probably migrate to DSSP3. DSSP3 can be tuned to be pretty strict with some work but by default its is very open. Also the system domain is very broad but it makes things so much easier. I am getting used to the DSSP3 policy design and I am starting to really appreciate some of the decisions I made.

Regardless, after I took care of the basics for confined privileged roles, the focus will be on wheel.id and on system services (short and long)

Categories
DSSP2

DSSP3 still ALIVE

Okay where do I start. So I was working on DSSP3 docs. Halfway through. And then I got this idea. I dont want DSSP3 to be like DSSP2-minimal. I want it to be like DSSP2-standard. So I threw the docs out of the window. I will use what I have later.

I started working on DSSP3, and truth be told, I did not know where it would lead me. I still don’t. However I made some progress and slowly but surely some of the pieces start to fall into place. It is a weird experience as I am used to the concept of least privileged and DSSP3 is basically the opposite. Imagine one big “system” domain that is essentially unconfined but not in a traditional sense as there are automatic transitions to confined domains that AFAIK cannot be overriden. These confined domains are usually system daemon , short and long. Its not really my focus now, as I am trying to work towards the bigger picture. Which means I am moving towards confined logins and confined root shells. Once some of that is into place, the whole broad outlines are drawn. It seems I am getting there, but I drew blood. I mean it’s give and take. There are way’s for a confined system agents to get to the kernel. Not sure about user agents yet, but many user agents are hybrid and thus system agents as well. Anyway’s some of the ways are: readwrite inherited unix dgram, stream sockets, tty’s, pty’s connectto unix stream sockets. write sock files, append and read files, sending null, child terminated and generic signals. Imagine DBUS, systemd –system, roots systemd –user, RPM/DPKG and root logins ALL running in that same privileged system domain. You can actually login directly in the system domain. As a matter of fact thats the DEFAULT behavior. You can block system logins though. Advanced users block this access and instead map logins to confined users. Also unknown permissions ALLOWED by default. Its just the opposite of DSSP2, were defaulting to open instead of strict. The root account is hybrid and so that presents you with a dillema. How do you treat it. Is it a user or the system. In DSSP2 its a user in DSSP3 root its the system. You login as root? You ARE the system. Obviously things are not as simple as root logins have real user specific aspects like a runtime user dir in /run/user/0.

Thats where I am right now. the basic system outlines are almost into place. Then I can more to confined logins and confined root shells. The policy is CIL but nothing like DSSP2 and it took me quite some time to get used to it. In the mean time i am trying to maintain DSSP2 as well so its switching between languages all the time. Theres a lot to be said about DSSP3 language, both good and bad but i am slowely starting to like it more. Its just better thought out but not necessarily cleaner in every sense of the word. Its just a difference balance.

Its nice though. I basically just follow my gut. I have some broad ideas of where it should go (see many “a model” article) but as for the details its just “go with the flow”. Same with my model for user sessions. I know what I want, I just do not know how to implement it. The suspense is there to say the least. We will see. Leveraging roles more. Hopefully less policy eventually but that is not a given!

Have a look at the source and see if you can appreciate some of the design decisions. Heck I am open to suggestions and feedback. Its kind of frustrating working on it alone but I enjoy doing it. Sometimes I go through some rough patches but sometimes I really enjoy victory. Its really like playing a strategy game. Something like Riskor chess. You need to think three steps ahead of the opposition. I would probably call this game TAME OR BE TAMED. The system is out to get you!!!

Categories
Uncategorized

A model

_______________________________________________________________________
|                                                                     |
|                      Linux/Initrd (targeted)                        |
|____________________________   ______________________________________|
|                             ^                                       |
|                      "The system manager"                           |
|                         (unconfined)                                |
|                  _________     _____________                        |
|                  |          ^              |                        |
|                  |                         |                        |
|                  |                         |                        |
|                  |        services         |   Unknown Services     |
|                  |       (targeted)        |                        |
|                  |                         |                        |
|                  |                         |                        |
|   root shell     |                         |                        |
|                  |_________________________|                        |
|                                                                     |
|                                loginshell (dont use this!)      <-(network)-
|                  |--------------------------------------------------|
|                  |         user_u/user_r/loginshell (targeted)  <-(network)-
|                  |--------------------------------------------------|
|                  |                                                  |
|             <- (sudo)-    staff_u/staff_r/loginshell (targeted) <-(network)-
|                  |                                                  |
|__________________|--------------------------------------------------|
|                  |                                                  |
|     root         |                                                  |
|     shell   <- (sudo)-      adm_u/adm_r/loginshell (targeted    <-(network)-
|  (targted)       |                                                  |
|__________________|__________________________________________________|
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.

Categories
DSSP2

DSSP3

I pushed an initial version of a next iteration of DSSP to Gitweb the other day. All things considering (especially the thing where I do this for fun) I am pretty satisfied with the result.

DSSP2 (standard) is and will in the foreseeable future be maintained as I use it on all my systems and obviously DSSP3 is not a substitute. I do plan though to create something equivalent to DSSP2 standard based on another iteration of DSSP (may well be DSSP3). I am not going to be rushed into it though. For now I will be working on DSSP2 as well as DSSP3 but I am not going to make any intrusive changes to DSSP2 (I guess I haven’t made any real intrusive changes to DSSP2 since version 0). DSSP2 will go into maintenance mode.

There is this one thing that bothers me more about DSSP3 than anything else. It is how I deal with filesystem identifiers. It is not consiistent with the remainder of the identifiers. In DSSP2 the various “partitions” are identified by the “partition name”. For example “dev” indentifiers are are in the “dev namespace”, files in “files”, fs in “fs” etc. The thing here is that filesystems are relatively unique in that you can only have one filesystem of each, where for example you usually have more than one file identifier or even for example have more than one config file identifier. Even when it comes to devices, as you have various classes of devices like terminals and storage and other nodes.

The way i designed it currently is that when you operate on an filesystem you end up calling a macro that is not prefixed with something that identifies filesystems. Instead the suffix identifies the identifiers as being a filesystem. Its a weird solution but I feel that its pretty elegant considering the circumstances. It should be obvious that I already decided to accept this implementation with DSSP3. Nonetheless it feels weird.

Also when you design a new policy from scratch it is kind of hard to anticipate how things are going to play out eventually. Until you fully leverage everything there can always surface aspects that you might not have foreseen. Anyway I guess I just wanted to vent my unease with the filesystem situation.

I am currently in the process of producing decent documentation for DSSP3. Writing is not one of my stronger skills and I still have some way’s to go but I do have three chapters that I am pretty happy with. Only about 13 or more to go.

I haven’t commited to DSSP2 for ten day’s but that is not only because of my work on DSSP3. Fedora has been pretty chaotic in the last few weeks as well and I decided to let this storm pass in hopes that things looked worse than they are. It looks like it my be prudent to wait some more as a recent mass-rebuilt still hasnt trickled down.

So for now its a focus on DSSP3 docs, then update Fedora/Debian and support any changes in DSSP2 for that, and then eventually decide on a way forward either with DSSP3 or maybe some other iteration. Ive also been contemplating my options for building on top a base. One of the other pain points of DSSP2 standard has also been that of “derived” domains. Things would be so much simpler if I could somehow do away with those. Seems as if this is easier said than done. I do have some ideas but I would have to sacrifice a lot in terms of niceness.

Then again, I do this for fun first and foremost. I like exploring. We’ll see. Just wanted to dump a blog about the current status.