Now as we've already seen,
we can see that our SELinux policy can store the correct context for files
within the file system, and we can make great use of this.
We can always go through and check the man page for semanage
and fcontext to get an idea of how we can start managing our
file context in the policy.
The file itself that stores information about the correct context can be listed.
We've got the path here.
If we wanted to move our home directory location,
we might want it from /home to /staff for some of our users,
so we might create a new home directory.
But of course, that's not going to have the correct context being set,
meaning that new user home directories created underneath staff
are not going to have the correct information.
One of the things that we can do is copy an existing context and
store it within our policy for the new directory.
So, using the ‑a option, we're adding a new set of rules.
We're using then the template of the home directory as an example,
and we're setting it on our staff directory.
With that done,
we can make sure that staff has the correct context by using restorecon.
If we now go through and list the staff directory,
we will see that it's been configured correctly.
And if we add a new user, here I'm just adding in a simple user called
u1 and setting their home directory location to be /staff/u1, when we
look at the u1 directory that's been created, it, too, will have the
correct information relating to a user home directory. So we can start
making the policies work for us by setting the correct context on the
parent directory.
Now here we're using it for our home directory, but it could be
equally needed when we need to set it up for a web server where we
need a web server to serve a new directory that's not underneath
the normal file system path.
So why don't we go through now to our command line and see how
we can set up a new home directory path.
Now, having already spent a little bit of time of
restorecon, if the context can be restored,
it must have been stored somewhere in our system, and that's inside of our
policy, which we can access through /etc/selinux/targeted. And then go
through and take a look in our context, and we've got a subdirectory that
we can pull up called files. In here, we've got a whole heap of different
files that store the context for directories and files within our file
system, and it's this directory structure that is being referenced by
restorecon.
Now this is going to be terribly useful for us because if I need to, as
we're going to do, relocate some of my home directories to a new
directory location, or if we need to go through and set a web server to
serve files from a new location,
we can make sure that it's stored correctly inside of our policy.
If I go through and take a look at the existing home directory,
we can see that its context is home_root_t. And if we take a look at our user's
home directory underneath that, we've got user_home_dir_t.
Now,
the root is nothing to do with the root user; it's just saying
it's a top‑level home directory that aggregates all of our
users' home directories together.
If we wanted to have some of our users have their
home directories underneath staff,
then we might go ahead and create the staff directory.
But if that's all that we do,
then we're going to get some problems later down the track,
because when I look at that directory,
it's got default_t. All subdirectories created underneath that are going to
have the same settings, so we're going to start to find that increasingly we
get problems for our staff users. To make sure that we don't have those
problems, we can set the correct context. And we can store that so it's set
correctly for subdirectories as well, our actual user home directories, by
using the semanage command and setting the file context inside of our SELinux
policy. We want to use ‑a to add a new policy, and we're going to use then an
example of the home directory, so we're really copying the context from our
home directory through to our staff directory. With this done,
we can hit the big Enter key. And it might take a few seconds, but
looking at this, it's taking maybe just too long.
And we've got to understand what's going on here. Now this is the
system that we were working with our Booleans on, and we said that
we've got a secure policy load that has been set.
Now, this means then that I can't properly reload my policy.
I've made the change, but we haven't been able to reload the
policy so we can show effectively that it's worked.
We have to remember what we've done.
I'm just going to go through and run a reboot.
I can't really change a lot at the moment. Rebooting.
I'm going to pick up on the default Boolean for my secure policy load, and
that's then going to be turned off, so I can then change the mode, I can go
through and reload my policy whilst the system is running.
If I go back now and look at logging back on once I've rebooted the system,
I'm then able to gain my root access again, so sudo ‑i. With that all in place,
I can up arrow key, I should be able to get to the same command,
I can run it again. Now here it's saying that it's already been
set, which is probably correct.
It just couldn't reload that policy. But if we're unclear
or don't want to lose any information,
we might choose to go through and delete the policy that we have for staff.
So we can go through and change the a to a d.
With that then deleted, we can up arrow again, go through our
history, using the template of home to set for staff, and now
it will definitely be configured.
We can also see it working with the use of the restorecon command. Again,
using the ‑v is going to print the information, and we're going to restore
the correct stored configuration for staff.
And we can see then that we've changed from default_t to home_root_t.
So everything then seems to be working.
But we also need to check our subdirectory structure.
So if I go through now and create a new user, so useradd ‑m to
make sure the home directory is created,
setting the directory path to be staff, and let's say user 1, I'm going
to create a user called user 1, with that, now when I go through and
check the u1 home directory using ls ‑dZ /staff and u1 with my fingers
very tightly crossed, I'm able to see then that we have got the correct
user_home_dir_t, and we can see the magic of storing the correct context within our policy.