Trusted Path Execution And AntiExecutables
A user commented on my guide for compiling the Linux kernel with Grsecurity and PaX patches and brought up Trusted Path Execution. I somehow missed this feature and I’d like to comment on what it does because it’s relevant to a conversation on another forum about Anti-Executables. So I’m going to look at TPE and go a bit more in depth about why I don’t find AntiExecutables to be useful for home users.
TPE is, essentially, an antiexecutable. There are three options:
- Partially restrict all non-root users.
- Invert GID option.
- GID for (un)trusted users.
1) Partially restrict all non-root users
Essentially this option stops a program of user ID X from executing a file owned by user ID Y. If a file is owned by root and only root can write to the file that file can be executed.
It seems like a fairly cool feature. What I like is that it enforces a consistent policy – the program that downloads the file is the program that can execute the file. It makes sense and it doesn’t get in the way as this behavior it enforces is the typical behavior a user should observe.
2) Invert GID option
The Invert GID Option changes the ‘GID for untrusted users’ into ‘GID for trusted users’ ie: it flips from a blacklist to a whitelist.
3) GID for untrusted users
Essentially if the GID is set to X then X can’t execute any files. If 2) is set to * and it’s really GID for trusted users then only X can execute files.
I Don’t Like AntiExecutables
Antiexecutables are fine for enforcing policies in the work place. If an IT Admin decides users can only install Word and Adobe Reader they can use an AE to enforce company policy via software policy. It’s great for this because the user does not own the machine and can not bypass the policy.
On a users machine the user is the boss, not the AntiExecutable. They can bypass these restrictions easily.
In neither of these situations is the AntiExecutable stopping an exploit from being successful. An attacker can do just about anything they’d like from a “RAM-Only” attack (ie: a remote code execution that never drops a separate executable file) as they can by writing to the disk. When you drop a shell into Reader.exe you inherit all rights of Reader.exe because you are Reader.exe – you live in that processes address space. So if Reader.exe can create a startup entry then, surprise surprise, so can you. And there’s your persistence since so many people believe that persistence is not possible if one uses an AntiExecutable (the issue of persistence can be more complex depending on the policy, but in my opinion if you’re relying on any traditional AE on its own persistence won’t be difficult to achieve).
An AntiExecutable doesn’t really make things much harder for an attacker. The way attacks typically work now is that you get shell and then you download and execute a new program. This is great because you can switch up your exploit and keep the same payload or you can switch up the payload and keep the same exploit. Either way, it makes things more flexible from a managerial standpoint and does virtually nothing to make things more difficult from an attack standpoint.
Again, if a clean program can do it the hacker who exploits that program can do it. If reader.exe can write to /path/to/x so can the attacker.
And this is why I wouldn’t bother with anything too crazy with AntiExecutables. I think the ‘Partially Restrict All Non-Root Users’ is great because it reinforces some common sense policy. That’s as far as I’d be willing to go – it does not really add significant security, hackers can do it all in RAM from their initial RCE.
On a server you don’t need flexibility and piling on security is basically the best thing you can do. Go ahead and use an AE – use anything, really. If you’ve got a Sys Admin sitting there watching logs then seeing access violations through the TPE could be a really strong indication that you’re being attacked. I leave that to the IT’s judgement here.
As a user you do need flexibility and convoluted policy can even make you less secure. You open yourself up to social engineering (yes, there are different levels of vulnerability here and different programs make you more or less vulnerable) and you complicate your setup. I don’t think TPE is really going to hurt you (especially the partial restriction) but it can be annoying without any real reason for use as a user.
Personally I’ll be using the partial restriction. Why? Not because I think it’s really making me a whole lot more secure… purely to see if it gets in my way and kind of a ‘well I may as well’ thing. I rely on the other security measures in Grsecurity to keep me safe and there are more than enough features in that patch to do so.
So, the conclusion here is simple, if you’re on a server pile it on. If you’re a user just use the ‘partially restrict all non-root users’ option. And, above all else, remember that neither of these should be relied on.
Edit: And as Brad Spengler (creator of Grsecurity) aka Spender has noted there are multiple other techniques implemented by Grsecurity that work with TPE to create a strong system. Grsecurity is obviously a very powerful set of patches and TPE is only one of many features.
blog comments powered by Disqus