[rsbac] Programs that drop priviliges

Amon Ott ao at rsbac.org
Wed Apr 4 09:19:23 CEST 2007

On Tuesday 03 April 2007 19:50, Sven Seeland wrote:
> I already have another question. I think I already know the answer
> but I want to be sure. Normally a program isn't allowed to
> MODIFY_SYSTEM_DATA on the capabilities SCD. If I have a program
> that is started as root and then wants to drop root priviliges I
> have to grant it the right to MODIFY_SYSTEM_DATA on said SCD
> (right?).

Yes. Maybe we should always allow reducing the cap set.

> If that program then drops the capability to change its
> capabilities it should no longer be able to acquire any
> capabilities, even though it has the right to MODIFY_SYSTEM_DATA on
> SCP 22, right?

It needs the SETPCAP capability to set any caps. It it dropped that, 
too, it cannot regain anything.

> Just want to be sure because I don't want somebody who manages to
> hack into my ntpd to be able to acquire all sorts of root
> priviliges.

That's a good idea. If you want to decide about allowed caps yourself, 
you can use the CAP module. It allows to set a max_caps set, so that 
the process will never have more caps than you want it to. The "show 
missing caps" kernel option to CAP (see its help) can show you all 
cases where you have been too strict.

And while we are at it: If you start ntpd with
rsbac_jail -dD -G ksyms -M rlimit mlock clock time_strucs ntpd
it will not even see any other process, and JAIL will deny any other 
kind of SCD access. If you are running RSBAC 1.3 and it has to 
connect to syslog, you should add -y and run your syslog with
rsbac_jail -Y -i -dD -t syslogd

Instead of using CAP, JAIL can also reduce the available Linux 
capabilities with -C <list-of-caps>

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

More information about the rsbac mailing list