RE: Bug in how capabilities

From: Jesse Pollard (
Date: Thu Jun 01 2000 - 10:17:23 EST

"Linda Walsh" <>:
> > From: Pavel Machek []
> > So what? I can not execute setuid shell, but I can freely do anything
> > I could do with the shell. I'll add myself to
> > ~root/.ssh/authorized_keys instead of running root shell. This is
> > called security by obscurity.
> >
> > (Still it can be a little bit usefull.)
> > Pavel
> > --
> > I'm "In my country we have almost anarchy and I don't care."
> > Panos Katsaloulis describing me w.r.t. patents me at
> >
> ---
> It's only a piece of the puzzle -- you came in via what route? A daemon
> running with LUID=daemon? Ooooo....LUID daemon is editing files in
> /root. I'd guess that would be a big-time redflag. Or say you
> managed to do an 'su' from user mrevil -- RT-Audit daemon (user-provided)
> detects that LUID=george is editing a root file, user mrevil is not
> in group 'wheel', or 'sysadmins' or is not in a known memory resident
> list of sysadmins -- bad mrevil...action:signal(SIGKILL).

Consider the effect of combining two layers:

   1. Capabilities (being violated as above)
   2. Non executable stack (and data segments)

Most of the penetrations using a stack overflow make only one library/sys call.
Using a setuid penetration to modify files in the way described above requires
the coordination of multiple calls (ie, a large attack function). The
combination of a CAP_NO_EXEC_STACK (nonexistant now) and a CAP_NO_EXEC_DATA
(for data space - leaving only the text segment as executable) would completly
kill the attack before it even started. Even being able to call a library
function to make a single modification would fail, since only one call
(open/close/read or write) would only affect the daemon itself - limiting
the damage to what the daemon could do via its' own functions, usually to
just generating bogus log file entries. Granted, if there were a single
function that opened a security file, writes a new entry, and closes the
file; then the protection is not as strong (unless the "writes a new entry"
doesn't get the data to write via the parameter list...).

Perhaps using two capability entries is overkill... maybe just one -

Jesse I Pollard, II

Any opinions expressed are solely my own.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:12 EST