Date: 18 Oct 1999 16:49:00 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: Jacques Vidrine <n@nectar.com> Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <xzp90503esj.fsf@flood.ping.uio.no> In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 09:26:33 -0500" References: <XFMail.991015111802.shelton@sentry.granch.ru> <Pine.LNX.4.05.9910150036170.5339-100000@jason.argos.org> <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no> <19991018142633.D1DDB1DA3@bone.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jacques Vidrine <n@nectar.com> writes:
> Further, I feel like most (all) calls to suser or what have you in
> the top of the kernel could be covered if we made the granularity ==
> syscall. This would break some abstraction, but if our hypothetical
> new suser or sec_permitted ``knew'' it was being called in the top of
> the kernel and ``knew'' what the current syscall was, our operations
> could just be table lookups. And especially for suser, we could
> tweak securelevel and jail stuff without having to modify the call
> to suser.
With all due respect, *yuck* :)
What EE suggested was to define a new SYSCTL macro to make defining
new security sysctls trivial. You'd do something like this:
static int sec_syscall_mount = 1;
SYSCTL_SECURITY(mount, &sec_syscall_mount, "Allow mounting filesystems");
int
mount(p, uap)
/* ... */
{
/* ... */
if (usermount == 0 && (error = suser(p)))
return (error);
if (sec_syscall_mount)
return (EPERM);
/* ... */
}
This is *very* rough; I don't think I'd actually use an explicitly
defined int like above; I'd rather use some kind of automagically-
defined symbolic constant and a function call / macro for checking if
it's set or not. This demonstrates the general idea, though; the rest
is implementation details :)
The sysctl knob would be named ``kern.security.mount'' or something,
and be one-way; its initial value would be 1, and you'd be allowed to
set it to 0 but not set it back to 1.
The current sysctl_kern_securelevel() would be rewritten to twiddle
the appropriate knobs, so that setting kern.securelevel would still
have the expected effect. Going the other way (translating security
settings into a meaningful kern.securelevel value) is not as trivial,
though, so userland programs which rely on *checking* the value of
kern.securelevel (as oppsoed to just *setting* it) may break.
DES
--
Dag-Erling Smorgrav - des@flood.ping.uio.no
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp90503esj.fsf>