Curt Sampson wrote:
> Err...I had kinda assumed that only root could tweak these. What sysctl
> knobs are there that someone other than root can tweak?

But that's just it.  If you look in init(8) at the kinds of operations
that are restricted at higher securelevels, in general they are all
operations that you would expect to be restricted to root anyway.
Immutable and append-only files that belong to the TCB are certainly
likely to have root ownership and restrictive permissions; the same
for disk and mem nodes, settimeofday, and the filter state. The point
of securelevel is to provide further restriction on operations that
are already restricted to root, when those operations could be
particularly useful to someone who manages to get some code to run
as root (generally an early attack step that does not entail having
an actual conversational connection to a root shell). The idea is to
place obstacles in the path of some likely ways that early-stage
attack code could proceed to leave a stealthily compromised system.
That's why the design requires a return to single-user mode (a
decidedly unstealthy move, likely to be noticed) to reset the
securelevel.

I'm sure the concern about sugid cores is that some sugid programs
may have security-related data in core that could be useful in
furthering an exploit.  But if you have a sugid binary on a production
machine that you want to debug, I don't think the securelevel restriction
should be too great an inconvenience - just arrange to tweak the sysctl
knobs at your next restart, or go single-user for 40 seconds to tweak
them, and return.

> With a commonly-available rootkit, these users are not very noticable
> anyway.

And it's just to protect against such common kits that there are
securelevel restrictions on operations that are already restricted
to root.

I wonder if a compromise would be conceivable, where a sugid process
would be allowed to make a syscall enabling /itself/ to dump core
(but not any other sugid process unless permitted by securelevel, and
not across an exec(2)). If you are trying to debug a sugid binary,
you're probably in a position to compile and replace it, and you
could replace it with a version that makes that enabling syscall,
while the system is running at elevated securelevel. Just a thought.

-Chap