[rsbac] RSBAC (jail) vs vserver (or other VPS)

[Amon Ott]

On Wednesday 13 June 2007 08:36, sftf at yandex.ru wrote:
>   Please, prompt me, what is "better" for implementing secure http
> service (apache) - RSBAC (with jail) or vserver in terms of:
>   - breakability
>   - isolation from other parts of the system
>   - simplicity of implementing clear and secure configuration (very
> important)

Personally, I am very happy with RSBAC and mod_rsbac, changing RC 
roles per virtual server. We do that in our Webserver product, which 
is also serving rsbac.org. Our helper scripts automatically create 
the upload user, the roles (virtual server and upload) and the type 
(data) by copying templates and setting some standard rights.

The whole scheme is drafted at 
http://www.rsbac.org/documentation/mod_rsbac

What specially pleases me is that I can control per virtual server 
whether (certain) users can be authenticated, mails can be sent, the 
database can be contacted, helper programs can be executed, etc. - 
without extra overhead. Calling suexec for different, user based 
rights would be significantly slower and provide less security 
(unless you use RC roles for the users).

Sure Apache also runs in a jail, but this is one global jail for all 
virtual servers. Individual Jails could also help, but then you need 
copies of helper files like PHP modules, external programs etc. The 
RSBAC jail is quite tight and hard to break out of.

> My last experience with RSBAC has shown that a RSBAC difficultly to
> configure because of of a plenty application parameters which need
> to be taken into account at the same time (files, devices,
> processes, resources...).

It allows very detailed control, I believe more than any other such 
system - this means there is a lot to configure, if you want to 
protect the whole system. Linux has so many ways to compromise it.

> Moreover, introduction of a Role Compatibility in production
> server, affects whole system (all daemons for example) and compels
> to configure tens of roles with hundreds of rules. It results in
> necessity to use ldd, strace, lsof, log analyzing and so on. And
> all the same there is no confidence, that all daemons operating
> modes are traced and there will be no problems in the future.

It is not that bad - you only need a rough setup to start with, then 
the log will show what is missing. Softmode and rsbac_debug_adf_rc 
are your friends.

Additionally, I recommend JAILs for all services. They are quick to 
setup - just wrap your program start with rsbac_jail command and a 
few options. We have extended our init scripts accordingly.

> But there are useful features which is in RSBAC and which are not
> present in vserver(correct me): - /dev/kmem protection

This is a killer issue - if your access control cannot 
protect /dev/kmem, ioports, disks, modules etc., you might as well 
use no protection at all.

> - power logging
> - user managment

New in 1.3 is the AUTHENTICATE right on USER targets. This means that 
you can restrict services to only check passwords of certain users, 
thus further protecting against brute force attacks on the admin 
account passwords.

> ...

- Separation of administration duty, so that admin tasks can be split 
up to avoid the superuser problem
- Detailed network access control with templates
- Individual /tmp directories with symlink redirection
- On-access virus scanning
- Resource control with RES module
- ...

> Whether something has changed in sense of clear, secure, fast
> configuration in RSBAC?

Sorry, there is no easier way yet. The whole system is very complex, 
and advanced models like RC still need the human brain for good 
results.

There are plans to provide a central default repository of Jail 
settings, RC roles and RC types, but it would need some funding for 
all the work.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22