The devices
subsystem in Cgroups provides a fine grained control for the system devices. An
admin can define Cgroups that can restrict access to particular devices and
define what users or groups can access those devices thus providing security
and data protection.
In this article we
will see how we can whitelist a device using Cgroups.
Add the Configurations
The first thing we
need to do is to add the configuration to the /etc/cgconfig.conf file with
group blockDevice {
devices {
# Deny access to /dev/sda2
devices.deny="b 8:2 mrw ";
}
}
In the above
snippet we have blocked the access to device /dev/sda2. The devices sub system accepts a parameter “devices.deny”
which takes the major and monitor numbers of the devices as values. Let’s see what
the value provides above tells,
B – Type of the
device. There are 3 types
- a —
applies to all devices, both character devices and block
devices
- b —
specifies a block device
- c —
specifies a character device
8:2 – Major and Minor
versions. These can found using
[root@vx111a dev]#
ls -l sda2
brw-rw---- 1 root disk 8, 2 Mar 15 14:24 sda2
brw-rw---- 1 root disk 8, 2 Mar 15 14:24 sda2
[Note: Major for
/dev/sda2 is 8 and minor is 2]
Mrw- access is
a sequence of one or more of the following letters:
- r —
allows tasks to read from the specified device
- w —
allows tasks to write to the specified device
- m —
allows tasks to create device files that do not yet exist
devices.deny - specifies
devices that tasks in a cgroup cannot access. The syntax of entries is
identical with devices.allow
Now once the
cgconfig file is configured we will move to the cgred configuration which will
add the process to the subsystems.
[root@vx111a tmp]# cat /etc/cgrules.conf
*:bash
devices
blockDevice/
Now I have added the
bash to the cgrules files. This makes that commands that are run from the bash
prompt which are trying to access the /dev/sda2 will be restricted.
Start the Service
Start both the
services using the commands,
Service cgconfig
restart
Service cgred
restart
Testing
In order to test
the Cgroups we need to first make sure that the PID for the bash prompt is
available in the cgroups created.
find the PID for the current bash Prompt using
[root@vx111a
docker]# ps -p $$
PID TTY TIME CMD
8966 pts/2 00:00:00 bash
PID TTY TIME CMD
8966 pts/2 00:00:00 bash
Check the lscgroup and
make sure that the devices subsystem is active as
[root@vx111a docker]# lscgroup | grep block
devices:/blockDevice
[root@vx111a docker]# lscgroup | grep block
devices:/blockDevice
Check the PID – Now
once the sub system is active we need to check the PID obtained above is
available in tasks file. This is a special file which contains all the PID that
are connected to the sub system. For checking the PID go to the location “/sys/fs/cgroup/devices/blockDevice”
and check the tasks file as,
[root@vx111a
blockDevice]# cat tasks
8966
9096
9638
8966
9096
9638
We can see that
8966 is available. Check the drive that /dev/sda2 is mounted
[root@vx111a tmp]# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 xfs 49G 207M 49G 1% /test
So we have the
device mounted on /test. Now from the bash prompt if we run a command that
access the /test drive the cgroups should not allow that. We can check using
[root@vx111a tmp]# dd if=/dev/sda2 of=/dev/null bs=512 count=1
dd: failed to open ‘/dev/sda2’: Operation not permitted
[root@vx111a tmp]# dd if=/dev/sda2 of=/dev/null bs=512 count=1
dd: failed to open ‘/dev/sda2’: Operation not permitted
We can see that the
current bash prompt does have the access on the /dev/sda2.
More to come, Happy learning J
