We will start, so I guess we can start.
Hello, my name is Radon Svaka, and I will be presenting how to harden a system with
a file access policy statement. So, I'll start with the brief introduction of the framework.
Can you hear me?
Is it better? Is it better? So, FEPO-CD is an acronym for file access policy statement,
and it's in a lightweight implementation of application-wide listing. It has many features.
I will just highlight that it has integration with RPM, and it can load some data from RPM
base, and it can log events to audit or syslog, and it heavily relies on FA Notify API from
kernel. So, when we look at this framework architecture, we can see several components
of the framework. The main component of the framework is the daemon. This daemon usually
listens to this FA Notify events from kernel. When it loads up, it reads all the data from
the backends, and it creates its own database, which is called trustdb. The first backend
is RPMDB, which handles data from RPM database, or metadata, better term, and the second
one is file backend, which loads all the trust information from user-defined trust lists.
There is also CLI component, which can manage trust and also the daemon's properties. So,
how does it work? When we look closer, we can see that it is on this image. There are
two processes on the system. The first on the left side is bash, and the second on the
right side is FA policy daemon. FA policy daemon is the situation listens for these events,
and it's just waiting. Bash is trying to execute PS command, and it calls exactly system call,
and this execution of the system call is on hold, so it's like post, and it's also waiting.
Meanwhile, on the other side can also send an event to the daemon that something is happening
on the system, and daemon can read from this event that there is some process called bash,
and it wants to accept this PS command, and it has PID 500, so it does a rules evaluation,
and when the decision is allowed, it sends affinity response to the kernel, and kernel
will let this exact V eventually finish with success. If the decision was denied, then
this exact V will return error code. So the daemon is the main part of the project, and
it works with the rules, and there are rules and trust, and both have power over what to
do with the files and their execution system. So these rules, they are pretty similar to
SC Linux, they have also subject object notation, and they start with the decision part. Decision
part is, it can be allow or deny, or it can be combined with syslog or audit attribute.
The second part of the rule is permission, which can be open or exec, but that refers
to the original system call from which that event comes from, and any is like place order
and will match both of them. We also support just these two because this is, because FA
notified us that. Our subject is what is executing, and object is what is being executed. So this
trust is a very important concept here in FA policy, it can be defined by user, and it
is usually done by CLI, and that there is also, or we don't have to add system binaries or
files to the trust, because they are trusted by default, they are loaded by this backend,
so this is done automatically, so when we run FA policy by default, it somehow works. So
these are some rules example, I don't know if you see them, but the first one says, the
first one allows loading of trusted shared libraries on the system, and the second one
opposed to that, like denies untrusted libraries. Third one will allow execution of trusted
files on the system, and fourth one allows using of scripts, which are trusted on the
system, and fifth denies untrusted scripts. And there are two cage of rules, first one
is for execution of all files, and the seventh is open for everything. So they are also
described here. So when we want to install FA policy demand, it's very simple, we can
just use normal Federa program for installation, which is called DNF, this is one liner, when
we install it, the installation consists of, or it installs three packages to the system,
the first one is FA policy, which is main package, which contains demon and CLI. The
second one is RPM plugin for FA policy, which works, or which, during the RPM transactions,
it sends the new metadata that are needed for correct behavior, so it sends it to the
demon, and then demon can work with them, and they are up to date, and it also notifies
the demon when the transaction ends, so it can behave, the demon can behave accordingly.
And the third one is service package for FA policy, with the service policy. So when
the installation is complete, we can start FA policy. There are several ways how to do
that. In our examples, we will use debug deny, because we are interested in deny events, or
debugging of the deny events, and we don't need anything more. If we would like to see
also allowed events, or something else, some other debug information, it can be done via
debug option, and when we want to run it on something more like production environment,
we can use system CTL. So when we run it, FA policy will tell us that it's listening for
these events, so it's okay, and we can start playing with this. So there are, I prepared
a few scenarios to demonstrate how it works. So the first scenario is called execution
of untrusted software. So I downloaded this file, this is Python script called exploit.py,
and I want to try to run it. I make it executable, and when I run it, I can see that it's blocked,
and we can see down there that there is deny event from FA policy that says that this exploit.py
is not trusted, so it cannot be run. So it blocked this unknown program to be.
Thank you.