"Linda Walsh" <law@sgi.com>:
> > From: Pavel Machek [mailto:pavel@suse.cz]
>
> > 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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
> > Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
> >
> ---
>
> 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 -
CAP_EXEC_TEXTONLY?
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:12 EST