FAQ

* What exactly is the "hardcoded_path" option?

It's for the extremely paranoid, and must be used with caution. When set,
everything outsdie of that path will be denied execution when execve(), mmap(),
or mprotect() is called on the given file, regardless of the file/directory
ownership or permissions, though those are still enforced. When combined with
the "paranoid" option, even root and the admin/trusted gids are restricted to
this path.

Run the script "scripts/generate_hardcoded_path.sh" to get a starting point for
setting this option. It walks down your path and determines all the directories
in which shared libraries are used.

This path may contain up to 1024 characters. If you need a higher limit,
increase the value of TPE_HARDCODED_PATH_LEN in module.h and recompile. Also,
no single directory can be more than 256 characters in length (MAX_FILE_LEN).

* Is this module compatible with my LSM? (SELinux, AppArmor, etc)

Yes, it is.

* How exactly does this module work?

This module uses ftrace to redirect certain functions from CONFIG_SECURITY to
functions in this module. From there, TPE logic is introduced.

* Why did I get a compilation failure when building this module?

Due to the continuing nature of changing interfaces between kernel versions,
this code may not compile correctly, or may even crash your system, if done on a
linux system not stated as supported. Use this module on non-tested kernels at
your own risk.

In general, though, the only issue I've seen so far when porting this module to
different kernel versions is data structure changes, which is solved by an easy
"#if LINUX_VERSION_CODE" statement. But future kernels may have big enough
changes to the point where the hijacking method I'm using no longer works, so
keep that in mind.

* Why isn't this using the Linux Security Module (LSM) Framework?

There are two main reasons:

  1) Because LSM no longer exports its symbols

This means that people have to recompile their kernel if they want additional
security modules not supported by their distribution.

Technically, this module actually does use LSM hooks, it just has to use a
rootkit-like method to hook into (hijack) them. But it also does things outside
of the scope of LSM, so to use LSM would mean to lose features.

  2) Because you can't "chain" LSM, meaning only one can be loaded at a time

Since you can't have more than one LSM loaded at a time, no distribution is
going to replace their preferred LSM with TPE. It's just not going to happen.

* Could this be done another way?

I suppose this can be done by changing the *_operations tables and alter the
pointers in some tables (ie; security_operations) to point to this module's
functions instead. Using ftrace is easier.

* Will TPE be put into the mainline kernel?

It wouldn't be very hard to port this module into the mainline kernel. However,
as far as I am aware, any security feature going into the mainline kernel is
being told to use the LSM framework. Since LSM only supports a single module,
and people wouldn't want to give up SELinux for TPE, perhaps a better approach
is to commit TPE into SELinux.

If you REALLY want these features in the mainline kernel, you're welcome to
give it a go. I'd love to see this go in.