Now we're going to spend just a little bit of time
understanding our AppArmor profiles.
An AppArmor profile is just a text file,
and it is a list of rules that are going to be applied maybe to our services,
but these also could be independent executables.
So we can protect both our services and our applications.
The profile can be enforcing where the rules are
enforced and violations are logged.
We can set to complain mode, isn't that a great word,
where we don't have any rule enforcement,
but we're able to debug what's going wrong with the service
or application by looking at the logged information and
trying to correct the issues.
But these are just a set of rules inside of our profiles.
Just because we have these rules doesn't mean that we have our services.
And although we've got 48 profiles,
we can see from the bottom output of aa‑status that
we don't have any active profiles.
Now, for the profile to be active, the command,
the executable, whether it's a service or just our application,
must be running.
And that's what we're going to take a look at now.
We're going to look at how we can read this information,
and we already know that we can do this with aa‑status,
but we're looking at say starting a service that is managed by a profile.
We can look at how that changes then with our aa‑status and
also take a look at our profile directory where the profiles
are stored in etc/apparmor.d.
Now, as we dive out to our openSUSE command line,
you know I'm going to encourage you to take a look at this yourself.
Running our aa‑status command,
we can go through and see that we've got this myriad of profiles,
but looking towards the bottom of the output,
we have no profiles with running processes either in
enforce mode or complain mode.
Now remember, these are then just sets of rules.
We have to have the corresponding service.
If I go through and take a look at installing maybe our NTP package,
there was a profile defined for NTP daemon,
so we can go ahead and run our zypper install ‑y.
The package is ntp.
We're going to allow this to cook through as it puts
on our time server and time client.
If I now go through and take a look, having installed it though,
of course the application, the service, is not running.
But if we start the service, I'm just going to start it,
it doesn't need to be enabled, it just needs to be running,
that process now is managed by AppArmor,
and we can see then that we have 2 processes have profiles defined,
and both of those are in enforce mode.
And we can see 7248 as one of our process IDs.
Now the really nice thing is that we're probably already used to
using the uppercases Z within our SELinux,
our previous module that we looked at,
but we have that same uppercase Z that we can use against processes.
So if I wanted to interrogate that process,
so process ID 7248, I can do so using my standard ps command.
So clearing our screen and running ps ‑Z,
for the process ID, so ‑p 7248,
and we can see then that we've got our label ntpd with enforce next to it.
So we could interrogate our whole system,
if we wanted to,
to just look at processes that were being managed by our AppArmor.
Now by being managed by AppArmor, we mean that they have a profile.
We can locate those profiles by looking inside of
our etc and apparmor.d directory.
And we can see then that we've got a whole load of
files representing then our profiles.
But because these are files, we can't really put the path name in their title.
So instead of having a separator as a forward slash
when we're looking at programs, we are using the dot separator.
We can see that a little bit more by clearing our screen.
If I use less, Esc + dot will bring up my last argument,
so I don't need to type that again, and if I look in usr.sbin.ntpd,
this is a file name, but it's obviously representing a file path.
When I open up this file, we can see that we can have our standard comments,
so with the hash or pound symbol, but if they are truly comments,
they must be followed by a space.
When we look at the include statement, that's #include with no space,
so that's a reserved word within the AppArmor language,
and it means then literally we're including additional parameters.
As we step our way through though, we have other inclusions.
We can start looking at adding in Linux capabilities,
so we can control which capabilities can be used,
we can control access to the network,
and then we have our list of files that the process is allowed access to.
And it's a closely‑confined list.
We can only access what is listed inside of our profile.
We'll learn more about these as we start looking at creating our own and defining our own profiles.