TPE LSM module for Linux

Implements something rather like AppLocker, wherein only root-owned executables can run:

https://github.com/cormander/tpe-lkm

On Debian Wheezy it needs modification in order to compile - the parameter "inode->i_op->check_acl" has to be removed from the parameters passed to generic_permission() on line 371 of security.c. Once this change is made, it compiles fine and works as intended; thus far (on Wheezy/amd64) I have not seen any stability issues.

(There are also some compatibility issues with newer kernels, e.g. 3.5.x. I may fork this project and see if I can fix those.)

To use it you just modprobe it (which is done automatically on install). To disable it you rmmod it. Very simple.

I'm not sure how useful this actually is, mind. It's probably overkill for most Linux desktop users, but may be grossly inadequate for servers. Probably worth putting it out there though.

 

So you have no problem inserting a new kernel module into memory?
Mrk

 

You mean the trust issues implicit in that? Good point. I am looking through the source code at the moment, and granted I'm not an experienced programmer by any stretch, I'm not seeing anything that appears to be nefarious - nothing that generates network connections for instance.

You're right though, there are trust issues. Stuff like this probably shouldn't be used in a production environment.

Edit: umm wait, do you mean that it should block module loading? Because module loading is always done as root, and TPE only affects limited users. I don't think there's much reason to apply TPE to root, seeing as root already has... root privileges.

 

I mean just downloading a bunch of code, compiling and Bob's your uncle.
Mrk

 

I'm afraid I still don't understand what you're getting at. As I said, it compiled without errors or warnings, and did not cause any stability problems as far as I could tell...

 

I'm getting at - you grab a bunch of code, compile it and insert it into the kernel. Did you carefully read the code to figure out what it does?

Besides, the idea goes against the user/root separation. You want as many things to run as user. You want services to run as their own users in their own chroot jail. What you propose is root only access. So if you need firefox, how will you use, as root?

Mrk

 

Well yes. I can't rule out the possibility that it does something seriously underhanded (I am not a kernel dev), but it doesn't do anything obviously nefarious AFAICT.

I'll also point out that the same issue could apply to various kernel patchsets.

What?

No it doesn't, and no I'm not proposing running Firefox as root. Limited users can run binaries that are owned by root:root. You run as a limited user, and only run binaries that have been installed by root and that your limited user can't modify. That is how TPE works, just like AppLocker on Windows, and while far from a perfect defense, it has worked well historically (even with shoddy userspace implementations like SRP).

Oh BTW. Say I'm running Firefox on Ubuntu Linux. I am running as the limited user gjones; the Firefox binary is /usr/lib/firefox/firefox, owned by root:root with permissions 0755. With what user's privileges does Firefox run?

 

It will run as gjones. And better yet, hopefully with gjones group too. And your user will not have access to all kinds of other dev nodes, and that's where the separation begins. If you need access to say the video device or disk, you will issue a system call, and you will get what you need, but if there's a problem with the system call, or a bug, then if it's owned by root, and it gets exploited somehow, you might get access to other parts of the system, through effective uid and gid during the execution. It's all lovely theory and such, but that's why chroot jails exist for services, with limited binary and lib sets, for exactly these reasons. And that's why apache runs as apache, and suchlike.

Whe you say worked well historically, you mean applocker ... well, perhaps, but we're not discussing windows here. The big problem in what you're proposing is a) the use of arbitrary code from the web, and b) using a tool without any real end state. What are you trying to achieve? Improve security? There are a million ways of doing that, and this could be one of them. Or not. Depends on the situation.

And if you might one day get tempted to grant permissions or use something as root because of this imposed limitation, you will in fact have compromised security rather than improve it.

Mrk

 

I prefer the Grsecurity implementation of partially restricting all users to only executing files that only root owns or that they own. Just easier.

I then use the TPE restrictions on a specific group (dnscrypt group that it runs as).

I don't see TPE restrictions as being an important security feature. But I like it for DNSCrypt in particular, and I like the partial restrictions since it's providing a policy that just makes sense - why should my browser be executing code that it doesn't own/ that root doesn't own? It probably shouldn't be. It doesn't really provide much though, it's just policy enforcement for the sake of consistency.

It's one of the 'lesser' features of Grsecurity. It's nice, and it belongs there, and I can see it working really well for specific systems, but otherwise it's nothing I need all too much as I already decide what programs can and can't execute through MAC policies.

 

Mrkvonic: gotcha. Whether TPE works as a security policy is definitely dependent on the use of the OS.