Date: Fri, 29 Jan 1999 12:49:33 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: arch@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <19990129124932.A34859@bitbox.follo.net> In-Reply-To: <199901271944.LAA15317@kithrup.com>; from Sean Eric Fagan on Wed, Jan 27, 1999 at 11:44:35AM -0800 References: <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> <199901271944.LAA15317@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm moving this to FreeBSD-arch, due to taking the discussion quite a
bit in that direction.
On Wed, Jan 27, 1999 at 11:44:35AM -0800, Sean Eric Fagan wrote:
> In article
> <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> you
> write:
> >The biggest impact of this is a new argument to the suser() call
> >all over the kernel:
> >
> > suser(NOJAIL, bla, bla);
> >or
> > suser(0, bla, bla);
>
> Oh, goody, more gratuitous incompatibilities with everyone else.
suser() is not generally compatible; the return value has different
(opposite) meanings in different OSes.
I do, however, think there are a couple of problems with the
implementation as outlined above, even if we ignore any
incompatibility arguments:
1. It is insecure in the face of changes. Any security policy should
default to deny; the above policy default to 'accept'. Later
kernel mods are likely to introduce security holes.
2. If more similar authentication mods are made, they also require
changes all over the system.
3. Policy is distributed everywhere, instead of a being concentrated
in one place, which makes it hard to verify.
I have been planning some changes for much of the same purpose. My
approach is to introduce a string identifing each context for suser(),
to allow people that want to hack on the authentication system an easy
place to start from. In a similar setting before, I've successfully
used a hierarchical system, going from less to more specific context
specification.
Example: a chflags in an FFS would be something like
"fs/chflag/ufs/ffs" while in an lfs, it would be "fs/chflag/ufs/lfs".
I've not thought much about the backend for this - if it is to be used
in general (instead of just as a good starting point for people that
want to do some authentication hacks on their machine), there should
probably be some way to express interest in just some of the nodes of
the tree the different authentication types form, and caching to avoid
string parsing.
If phk would be satisfied with a slightly hackish solution for the
time being, we could introduce the above, and just use string compares
for his acceptable cases for the time being. This could be done as a
binary tree, so it wouldn't be quite as expensive as it sounds.
Context for the people not having done their own source investigation
of credentials use:
We have approx 180 root checks using suser():
eivind(bitbox)--% glimpse -y suser | wc -l
185
We have approx 90 checks for root that are NOT done using suser(),
rather using explict comparisons with 0:
eivind(bitbox)--% glimpse -y cr_uid | grep 0 | wc -l
94
Another interesting statistic for root mods probably is the number of
cr_uid references in the kernel (all of these should be inspected):
eivind(bitbox)--% glimpse -y cr_uid | wc -l
283
If you're thinking of a full-blown look at capabilities, cr_gid is
used 28 places, cr_groups 60, and cr_ngroups 52. Given the relatively
low number of credentials uses (less than 400), it shouldn't be more
than a couple of evenings worth of work to collapse it all back to a
set of function or macro calls, creating a much more suitable
environment for capabilities hacking.
Eivind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990129124932.A34859>