TrustedBSD – MAC Processes

We create open-source because we love it, and we share our finding so everyone else can benefit as well.


TrustedBSD – MAC Processes

As we continue on looking at the MAC modules, we will cover two more minor modules that will allow us to add MAC Processes. This will prove crucial to learning some of the more advanced modules that deal with policies. These two modules are mac_seeotheruids, and mac_partition. While they are simple, they are still good modules to keep in mind for a complete implementation.

This was also previously posted on Screaming Electron.

If you haven’t already, be sure to read the article TrustedBSD – Mandatory Access Control.

Preparing for MAC Processes

The module’s name tells exactly what it does, it controls the ability to see other uids; the other uid’s processes to be exact. The first thing we want to do is load the module:

$ kldload mac_seeotheruids

By doing this, the sysctl oid ‘security.mac.seeotheruids.enabled‘ is automatically set to “1” (enabled).

With the module enabled, let’s take a quick look at what we can and can’t see in the process list.

# sysctl -w security.mac.seeotheruids.enabled=0
 security.mac.seeotheruids.enabled: 1 -> 0

> ps ax | wc -l

# sysctl -w security.mac.seeotheruids.enabled=1
 security.mac.seeotheruids.enabled: 0 -> 1

> ps ax | wc -l

# ps ax | wc -l

As we can see, after reapplying the module, the regular user was limited to seeing only the processes belonging to the user itself. Of course, in the last shell command, we can see that the root access user can still see everything.

Now, if we want people of the same primary group to see each others processes, we can do so with another oid. Using ‘sysctl -w security.mac.seeotheruids.primarygroup_enabled=1’ will allow any users of the same primary group to see the processes of other members that have the same primary group. This could be good for groups of administrators, or technician, but probably not as important for the general user.

The last option for the module is the ability to allow a specific group to over-ride the restrictions of the module. First we enable the feature:

# sysctl -w security.mac.seeotheruids.specificgid_enabled=1

Now we can set the specific group with another oid. Let’s see how it works.

> id -G
> ps ax | wc -l

# sysctl -w security.mac.seeotheruids.specificgid=1002
security.mac.seeotheruids.specificgid: 0 -> 1002

> ps ax | wc -l

2> id -G
2> ps ax | wc -l

This module would probably be best for system admins, since only one gid can be specified. Remember that you also have to use the numerical value of the gid. This is really am important module even if it doesn’t seem to be much at first, but you have to remember, any nosey user could map out a server just by the processes alone.




security.mac.seeotheruids.specificgid: 0
security.mac.seeotheruids.specificgid_enabled: 0
security.mac.seeotheruids.primarygroup_enabled: 0
security.mac.seeotheruids.enabled: 1

MAC Partitions

Like the seeotheruids module, this one can be loaded the same with:

$ kldload mac_partition

With this the oid will default to being on.

Both mac_seeotheruids and mac_partition work hand-in-hand. While mac_seeotheruids controls what users see, mac_partition tells allows processes to tell a user what they can see. What the module actually does, is allows you to set process to a certain “partition” (not to be confused with a filesystem disk partition).

First, we need to add a class to /etc/login.conf. For testing purposes, I just added a new class after the default class.


After that, run ‘cap_mkdb /etc/login.conf’, and then set the class with the pw utility.

# pw usermod MacUser -L testing

> whoami
> getpmac

Setting MAC Processes

So, now we have run across another tool, getpmac. While we are at it, let’s also mention, setpmac. These two tools are used to get the info of a process label, and set the label of a process. We can use getpmac to see the user’s label access and the label of a process using the ‘-p [pid number]’ argument. Another helpful addition to point out, is the “Z” argument in ps. This argument shows the labels of the processes listed.

> ps axZ
partition/10 3220 ?? S 0:00.07 sshd: MacUser@ttyp2
partition/10 3221 p2 Ss 0:00.10 -tcsh (tcsh)
partition/10 3624 p2 R+ 0:00.00 ps axZ
> getpmac -p 3221

Ok, now that we have set a class to a partition, and know how to set and look at labels, let’s see how it all works out. First off we will turn mac_seeotheruids off, so that we can see the raw nature of the module.

# sysctl -w security.mac.seeotheruids.enabled=0
security.mac.seeotheruids.enabled: 1 -> 0

# setpmac partition/10 systat

> ps ZU root
partition/10 3452 p0 S+ 0:00.08 systat

# sysctl -w security.mac.seeotheruids.enabled=1
security.mac.seeotheruids.enabled: 0 -> 1

> ps ZU root

We set the partition of the process to match the partition of the user, and then the user was allowed to see the process. Once we set mac_seeotheruids, the ability to see the process was removed. Mac_seeotheruids takes priority over mac_partition, but still has ability to add to the security when used in conjunction. Keep in mind, that partition “0” will always take priority over the partition labels. Anyone of the wheel group will still be able to see the processes of the other users regardless of the partition setting on a process.

How will we use these two together in an actual business situation is quite simple. If you are allowing primary groups to see other processes, you can set users from the same primary group to different partitions.

Primary group: Users

Joe Partition/10
John Partition/10
Joan Partition/11
Lisa Partition/11
Max Partition/15

In a situation like this, we are separating people in sub-groups, but without having to deal with the DAC (discretionary access control) caveats. Say Joe and John are in the accounting department, and Joan and Lisa are in the HR Department. Max, he’s in accounting as well, but being a new employee, we don’t trust him just yet. So, what we’ve done is given each department a partition, and the new user a semi-trusted partition.



So, now you can see how we can take advantage of these modules. While it might not seem like a huge security risk, think about jail processes, private servers running on the server, and various other things you really don’t want everyone to know is running on the server.

Ready for more? Be sure to check out MAC BIBA TrustedBSD : Part 3.

No Comments

Add your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.