And we're going to move out to our command line now where we're going
to look at how we can manage our SELinux contexts, so viewing our
contexts and changing the contexts, and seeing the effect of having
changed those contexts. But remember, take care of your own systems
because we're deliberately trying to manipulate the system to stop
things working.
If yours is not a test system, then certainly don't
be working through it on this lab.
Now to begin with,
I'm just going to elevate some of my privileges, so I'm going to use sudo ‑i,
so I'm now then running as the root account. This should give me full access to
everything, or at least you would have thought,
wouldn't you?
Well, let's go through and just take a look at our file system.
If we go through and take a look at the context of our /etc/shadow file, so
where our passwords are stored and our aging information,
we can see the type of this context is shadow_t. And that's
the main enforcement that we are using.
Any process that accesses this must be using a compatible type.
If I go through and take a look at my current processes,
obviously, I can just run the ps command and it will list then the processes.
So I've got sudo, bash, and ps. If I want to though go through
and take a look at the SELinux context of those, then pretty
much, again, they are all unconfined.
They're user processes, and they don't really relate to any of our SELinux
rules, so they're just set as unconfined. However, certain commands that
we start up will run with a certain context.
We're going to be able to see what happens when we go through and
start mucking about with some of these contexts. We might want to be
learning some information, but as I say,
be very careful about the type of system that you're working on because
as we're going to demonstrate, we can show how even as a root user, we
can be denied access through to our system.
So I'm going to clear my screen. If I go through and do an ls ‑Z for the
current directory dot, it's not showing anything, but let's go through and
just include then the d so we know we're looking at our directory. And now we
can start seeing the context coming back.
So we've got admin_home_type.
Now, you might be a little bit curious and just thinking,
well, what happens if I set this type on my shadow file? So
we can use then the chcon command, changing the type to
admin_home_type for our /etc/shadow.
There you go.
That doesn't seem to have broken anything, does it?
Hang on.
I'm just getting a quick call.
Somebody wants to go through and start checking some aging information.
So if I go through and use the chage command, when
I'm looking at the chage command,
I can go through then specify that I want to look at listing the
information for my own user account, so that's going to be vagrant.
It might be different on your own system.
And then it's like, whoa, that's very strange.
We're unable to open up the shadow file.
We are running as root, but we have a problem.
And the problem is the context.
Now we know that we've just changed it, but the reality is we
can go through and try and debug some of this.
We might not know why. And again, if we have then our permissive mode turned on,
we wouldn't see any problem, but it would be logged.
We're in an enforcing mode, so we're not allowed to go ahead
with this, but it's still going to be logged.
So let's go through and look for our module avc.
And if we use the time stamp, or it's actually time start,
but we can then go through and say recent, so this is then within the
last 10 minutes, we only see then those avc denials that are coming in
within the last 10 minutes. And we can see then that we've got a
denial using the command chage, and when we go through and take a look
at the source context,
it's passed wd_t, and it's trying to access a target context of admin_home_t.
So this is where our problem is we can probably quite easily see we've got
the wrong context. But we also installed setroubleshoot .With
setroubleshoot, they can try and make this more readable. Now sometimes it
works, sometimes it doesn't, as to how more readable we get our message. But
if I go through and grep for sealert inside of /var/log/messages, so our
standard log file, we've got our most recent sealert here, so let's go
through and grab this. And we can see SELinux is preventing chage from read
access to the file shadow. For a complete message, we can then go through
and paste this in, execute, and here it gives me maybe some better idea.
So yes, we've got our preventing chage from reading access. It
then gives me 100% confidence that this is going to fix it, but
it's probably a little bit too much work.
It's actually then going through and say, well, okay, let's search for that.
Let's create a module with audit2allow, and then let's
go through and install our module.
That module then would be allowing access from passwd through to
admin_home. And that's probably not what we need to do.
We've just got the wrong context set. So sometimes it comes up with the
really good suggestion; other times, the suggestion has just gone a little
wayward, as in this case. But of course, we can go through and fix this
problem. We could fix it with chcon, but we could also go through and fix
it with restorecon. If I use ‑v,
that will show me what is changing from and to. Restorecon is reading
from our SELinux policy and looking for what has been configured for
our shadow file and setting it correctly from the policy. So I can go
through then and put /etc/shadow.
Just put the correct context on for that file.
We've relabeled it from admin_home to shadow_t. So we've got everything
now configured correctly, and we didn't need to know too much about it,
other than using the restorecon command.
But it does just show you how SELinux works, and how even it affects us as
the root user, but as I say, take great care when running on your systems, as we don't want to leave you in an unusable state.