Kernel_Killer
July 6th, 2007, 17:31
Introduction
As we continue on looking at the MAC modules, we will cover two more minor modules that will prove crucial to our learning of some of the more advanced modules that deal with policies. These two modules are mac_seeotheruids, and mac_partition. While they are very simple, they are still good modules to keep in mind for your final implementation.
MAC_SEEOTHERUIDS
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 with, 'kldload mac_seeotheruids'. By doing this, the sysctl oid 'security.mac.seeotheruids.enabled' is automatically set to "1", in other words, enabled.
Like Part 1, we will use "#" for the root access shell, and ">" for the regular user.
So, 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
103
# sysctl -w security.mac.seeotheruids.enabled=1
security.mac.seeotheruids.enabled: 0 -> 1
> ps ax | wc -l
5
# ps ax | wc -l
103
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
1002
> ps ax | wc -l
5
# sysctl -w security.mac.seeotheruids.specificgid=1002
security.mac.seeotheruids.specificgid: 0 -> 1002
> ps ax | wc -l
113
2> id -G
1001
2> ps ax | wc -l
5
This module would probably be best used for system admins, due to the fact that 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.
loader.conf
mac_seeotheruids_load=YES
sysctl.conf
security.mac.seeotheruids.specificgid: 0
security.mac.seeotheruids.specificgid_enabled: 0
security.mac.seeotheruids.primarygroup_enabled: 0
security.mac.seeotheruids.enabled: 1
MAC_PARTITION
Like the seeotheruids module, this one can be loaded the same with 'kldload mac_partition', and 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 puposes, I just added a new class after the default class.
testing:\
:label=partition/10:
After that, run 'cap_mkdb /etc/login.conf', and then set the class with the pw utility.
# pw usermod MacUser -L testing
> whoami
MacUser
> getpmac
partition/10
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
LABEL PID TT STAT TIME COMMAND
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
partition/10
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
LABEL PID TT STAT TIME COMMAND
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
LABEL PID TT STAT TIME COMMAND
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 turned mac_seeotheruids back on, 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. Also, 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 a process is set to.
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.
loader.conf
mac_partition_load=YES
Conclusion
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. Later we will discuss how we will make all system-wide processes start with specific partitions. Until then, enjoy, and experiment!
Copyright Network Synapse (http://www.networksynapse.net)
As we continue on looking at the MAC modules, we will cover two more minor modules that will prove crucial to our learning of some of the more advanced modules that deal with policies. These two modules are mac_seeotheruids, and mac_partition. While they are very simple, they are still good modules to keep in mind for your final implementation.
MAC_SEEOTHERUIDS
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 with, 'kldload mac_seeotheruids'. By doing this, the sysctl oid 'security.mac.seeotheruids.enabled' is automatically set to "1", in other words, enabled.
Like Part 1, we will use "#" for the root access shell, and ">" for the regular user.
So, 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
103
# sysctl -w security.mac.seeotheruids.enabled=1
security.mac.seeotheruids.enabled: 0 -> 1
> ps ax | wc -l
5
# ps ax | wc -l
103
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
1002
> ps ax | wc -l
5
# sysctl -w security.mac.seeotheruids.specificgid=1002
security.mac.seeotheruids.specificgid: 0 -> 1002
> ps ax | wc -l
113
2> id -G
1001
2> ps ax | wc -l
5
This module would probably be best used for system admins, due to the fact that 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.
loader.conf
mac_seeotheruids_load=YES
sysctl.conf
security.mac.seeotheruids.specificgid: 0
security.mac.seeotheruids.specificgid_enabled: 0
security.mac.seeotheruids.primarygroup_enabled: 0
security.mac.seeotheruids.enabled: 1
MAC_PARTITION
Like the seeotheruids module, this one can be loaded the same with 'kldload mac_partition', and 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 puposes, I just added a new class after the default class.
testing:\
:label=partition/10:
After that, run 'cap_mkdb /etc/login.conf', and then set the class with the pw utility.
# pw usermod MacUser -L testing
> whoami
MacUser
> getpmac
partition/10
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
LABEL PID TT STAT TIME COMMAND
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
partition/10
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
LABEL PID TT STAT TIME COMMAND
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
LABEL PID TT STAT TIME COMMAND
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 turned mac_seeotheruids back on, 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. Also, 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 a process is set to.
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.
loader.conf
mac_partition_load=YES
Conclusion
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. Later we will discuss how we will make all system-wide processes start with specific partitions. Until then, enjoy, and experiment!
Copyright Network Synapse (http://www.networksynapse.net)