Date: Sat, 22 May 1999 11:19:25 +1000 (EST) From: Warren Toomey <wkt@henry.cs.adfa.edu.au> To: security@FreeBSD.ORG Subject: Re: Lowering securelevel from console? Message-ID: <199905220119.LAA15588@henry.cs.adfa.edu.au> In-Reply-To: <199905211555.LAA23107@khavrinen.lcs.mit.edu> from Garrett Wollman at "May 21, 1999 11:55:10 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In a previous article, I asked about the pros/cons of allowing a root process
which had the console as its controlling terminal to be able to lower the
kernel's securelevel. What I'm suggesting (in pseudo-code) is:
static int
sysctl_kern_securelvl SYSCTL_HANDLER_ARGS
{
. . .
if (level < securelevel) {
if (not superuser or controlling terminal is not console)
return (EPERM);
}
securelevel = level;
}
Dima Rubin replied:
Enabling securelevel changes from the console w/o breaking into the
debugger is potentially dangerous.
Garrett Wollman replied:
A rogue root process could use the debugger to take control of another
process (e.g., getty) and force it to disengage security.
I think I understand the issue: if someone can break in as root, at the
present they cannot lower the securelevel without rebooting the system.
With the changes above, they could hijack getty (which runs as root and
has the console open) and use it to lower the securelevel.
I'd still like to have the ability to temporarily lower the securelevel
without having to suffer the delay of a reboot. Is this essentially
infeasible, or are there any ways of authenticating the `real' super-user?
Ideas of building a one-way hash function and a hashed password into the
kernel have just floated into my head, but that seems like overkill :-)
Thanks for the feedback!
Warren
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905220119.LAA15588>