Hi all,

I've been asked to try and explain the basic and most important things that the gresec kernel patch does from the point of view of a enhancing security - for hosting in particular.

This is so that similar features, or a subset of the patch, can be incorporated into the Virtuozzo kernel at some point (apparently the complete patch is a no-go for technical reasons).

Unfortunately I can't put this into words because my knowledge is so limited.

I could only manage "prevents the apache process from running any executables unless they are user-flagged as being OK and owned by root" as being a single example of what it can do.

But wider reaching details of what it really does is beyond my ability - I have no idea how to say it in words - and which bits are the most important are unclear - most probably because I don't understand the details.

Can anyone help me with this (especially Scott - if you'd be willing? Please?) ?

Faris.

from the grsec website:

grsecurity is an innovative approach to security utilizing a multi-layered detection, prevention, and containment model. It is licensed under the GPL.
It offers among many other features:

* An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
* Change root (chroot) hardening
* /tmp race prevention
* Extensive auditing
* Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
* Prevention of arbitrary code execution in the kernel
* Randomization of the stack, library, and heap bases
* Kernel stack base randomization
* Protection against exploitable null-pointer dereference bugs in the kernel
* Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
* A restriction that allows a user to only view his/her processes
* Security alerts and audits that contain the IP address of the person causing the alert

Thanks Scott, but that's not quite what I'm after but its my fault - I'm just struggling to explain what I'm after.

But ignoring that - Is it the RBAC that, out of the box, does the magic of preventing apache from executing a file? Or are there some additional rules that you have added that that get applied by default in your RPM that make this happen?

Faris.

that is called Trusted Path Execution, where any member of the group "untrusted" can only execute commands owned by root. There are 2 other groups in this policy that are implemented but not used, one is called "server" and the other is called "client". Members of the server group can only act as a server, meaning if you put apache in it, it could only accept connections, it could not initiate. Client is the opposite. Its not part of the RBAC system directly, but I suspect it leverages some of the same code.

Aha. This is exactly th kind of thing I'm after.

I take it everybody other than root is in the untrusted group?

youve got to add someone to the untrusted group to implement the policy. We're doing that for some fixed users during the install process. Theres also an unused mode that inverts the logic, to create a "trusted" user group. We're still looking at the best way to implement that in the context of a plesk environment. Right now we can avoid issues with cgi-bin or ssi users by only putting apache in the group by default. In the inverted model we'd have to come up with a way to figure out all the valid cgi-bin/perl/etc users during the install process. Its doable, but I think the effort in coming up with that could be better spent elsewhere for greater gains.

Thanks Scott. That's exactly the kind of info I'm after. I fear it will do not good in the end (i.e. it won't be implemented), but I can hope and try to push as much as I can.

Faris.

There are 3 ways to sell security:

1) Fear
2) Because you have to (PCI DSS, HIPAA, etc)
3) It lets you do something you couldnt before (ecommerce, etc)

grsec itself is just a small piece of the overall ASL suite. One thing we were talking about was to include the ability to selectively enable it by the domain, so you could use it as a sales tool (PCI DSS compliance for example).

Virtual Patching would be the other side of the coin, where you lower costs by reducing the amount of effort required to implement fixes.

Thanks Scott.

Well, it looks like a big chunk of grsec will indeed be implemented - thanks to your help which allowed me to explain it in a more sensible way.

Faris.

Scott,

If you have time to further my education on TPE....

Without grsec/TPE, with regards to noexec on /tmp, you pointed out to me at some point in the past, it is too trivial to get round it.

For example, all you need to do is run an interpreter like perl or python on the file. e.g. perl /tmp/blah will execute the contents of /blah even if /tmp is noexec

Or you just put the file in some other directory that allows execs.

But with TPE this is prevented, and globally, not just in /tmp. Apache (or whatever users you have in untrusted) can't run /tmp/blah nor perl /tmp/blah ?

Err...now that I have written this down I realise I must be missing something or that I have got something wrong because if this is the case how do cgi-perl scripts run in /cgi-bin (or php scripts etc). I thought it was because php and perl are owned by root. But if that's all it is, how does TPE stop perl /tmp/blah ?

Faris.

The default TPE policy is vulnerable to the same thing as noexec in that regard. perl is owned by root for example, therefore it can be run by an untrusted user. The difference between the two are that noexec is confined to the specific mounted file system. TPE is universal.

Expanding on that further, the TPE policy we're testing now on the 2.6.22.x kernels adds another dimension that restricts the system level exec() function to a specific list of allowed commands, eliminating the bypass above. We can even make a honeypot out of it... ie it looks from apaches side that we're letting you execute commands, but in reality its just logging them.

cgi-bin is different because of suexec, the scripts run as the user, which by default are not in the untrusted group, therefore the TPE policy doesn't apply.

Thanks Scott,

I see. Hmm....so technically, from the cgi-bin point of view, would it be sensible to add each user (as created when a domain is added to a client account) to the untrusted group if this is possible in real time?

Ye gods we really need you on board with Virtuozzo somehow Scott. The world needs a VZ security specialist and it doesn't have one. Hopefully some of the changes being made at the moment will offer an improvement but it needs someone who knows that they are talking about to push it further.

Faris.

ASL works on virtuozzo now, as well as vmware, xen, kvm, lguest, etc. The kernels are the only piece that arent available on virtuozzo.... since kernels arent available on virtuozzo.

Hmmm. It got really borked when I tried it a few weeks ago. I'll try again.

Faris.

The VZ kernel devs have added TPE support from the grsec patch in the latest kernel. Yipee!

The configurable items are: tpe_gid, tpe, tpe_restrict_all, and grsec_lock

Now to figure out how to test it. What settings for do you use for these in your RPM Scott? (I assume one or more of these is an enable/disable flag)

Faris.