Date: Mon, 18 Oct 1999 09:26:33 -0500 From: Jacques Vidrine <n@nectar.com> To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <19991018142633.D1DDB1DA3@bone.nectar.com> In-Reply-To: <xzpso392gj0.fsf@flood.ping.uio.no> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[I meant for this to go to -arch instead of -security]
On 18 October 1999 at 10:56, Dag-Erling Smorgrav <des@flood.ping.uio.no> wrote:
[snip]
> I'm starting to think that secure levels should be implemented as
> bitmasks, with one bit for each operation or group of operation to be
> allowed or denied (0 = allow, 1 = deny). The if statement above could
> be rewritten as:
>
> if (securemask & SEC_MOUNT)
> return (EPERM);
>
> Using a simple bitmask might be too simple though (it would restrict
> us to 32 or 64 distinct operations), so we might want to hide the
> actual implementation behind a function call or macro:
>
> if (!sec_permitted(SEC_MOUNT))
> return (EPERM);
I've been thinking about something similar for suser, so that all uses
of superuser privileges can be audited. For example, some
hypothetical suser2 API that takes as one argument a constant
specifying the category:
int
setuid(...)
{
...
error = suser2(p, SUSER_CREDS)
...
}
only for this to be truly useful, all calls to suser would have to be
changed to suser2. This is the same kind of thing that DES is
demonstrating above with the hypothetical sec_permitted.
Chatting with DES on IRC, it seems to me that all this stuff (jail,
auditing, securelevel) needs to fit together.
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.
--
Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org
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?19991018142633.D1DDB1DA3>