simple tpe implementation

Elad Efrat <elad <at> NetBSD.org>
2007-02-01 22:41:00 GMT

hi,
attached is a very simple patch that adds a "security.tpe" sysctl node
to control a tpe (or, trusted path execution) feature.
what it does: prevent execution of any program that does not live in a
directory that is owned by root and writable by neither group or other.
why would you need it: quick knob you can enable to prevent any users
from running their own stuff. kinda useful if there's a now 0-day out
or you're in the middle of patching your system or whatever.
caveats: it doesn't use kauth yet. if it could it would, so let's not
get into that now. it also doesn't address interpreters (i.e., someone
starting python and feeding it stuff) yet. we will do that -- we have
the mechanism in place, but I'm holding it back for now.
default: disabled.
demo:
phyre:elad {8} test/hi
hi!
phyre:elad {9} su
Password:
phyre:elad {1} sysctl -w security.tpe.enabled=1
security.tpe.enabled: 0 -> 1
phyre:elad {2} exit
exit
phyre:elad {10} test/hi
test/hi: Operation not permitted.

Re: simple tpe implementation

Perry E. Metzger <perry <at> piermont.com>
2007-02-01 23:14:08 GMT

Elad Efrat <elad <at> NetBSD.org> writes:
> attached is a very simple patch that adds a "security.tpe" sysctl node
> to control a tpe (or, trusted path execution) feature.
Neat.
Wish list: it would be cool if someday this could be turned on/off on
a per process basis somehow. I'd love to have things like
chrooted/unprived daemons running with this on for themselves and
their children, even if other processes are "normal". NOTE: This
doesn't mean I don't favor committing this now.
Perry

Re: simple tpe implementation

Elad Efrat <elad <at> NetBSD.org>
2007-02-01 23:47:16 GMT

YAMAMOTO Takashi wrote:
> i have no good idea off hand.
:)
> VOP_ACCESS is the right way to check permissions,
> but it doesn't have "only root can.." functionality.
> we can change VOP, but it's almost impossible to implement
> for some filesystems.
right. however, let's separate the interface from the implementation.
the first we want to add. the second, though questionable, will cover
most environments -- we can always document caveats like we already
do for some subsystems.
later on, when we have better ways of implementing it, it will be
changed (like many other things); that's why the posted diff adds
static vars only...
-e.

Re: simple tpe implementation

Steven M. Bellovin <smb <at> cs.columbia.edu>
2007-02-02 08:04:16 GMT

On Fri, 02 Feb 2007 00:41:00 +0200
Elad Efrat <elad <at> NetBSD.org> wrote:
> hi,
>
> attached is a very simple patch that adds a "security.tpe" sysctl node
> to control a tpe (or, trusted path execution) feature.
>
> what it does: prevent execution of any program that does not live in a
> directory that is owned by root and writable by neither group or
> other.
>
> why would you need it: quick knob you can enable to prevent any users
> from running their own stuff. kinda useful if there's a now 0-day out
> or you're in the middle of patching your system or whatever.
>
> caveats: it doesn't use kauth yet. if it could it would, so let's not
> get into that now. it also doesn't address interpreters (i.e., someone
> starting python and feeding it stuff) yet. we will do that -- we have
> the mechanism in place, but I'm holding it back for now.
>
>
Interesting, though I need to think about it a bit. (Thinking is
definitely advised; I just realized that one objection I had wasn't
valid...)
--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: simple tpe implementation

Christian Biere <christianbiere <at> gmx.de>
2007-02-02 16:47:39 GMT

Christian Biere wrote:
> YAMAMOTO Takashi wrote:
> > > + /* XXX Must be owned by root. */
> > > + if (va->va_uid != 0)
> > > + return (EPERM);
> This would also break any setuid-non-root executable, right?
What I mean is: This denies execution of any executable not owned by root.
For example, none of my pkgsrc application are root-owned but rather a dedicated
user. This case might be neglible but, for example, there are a few executables
even in base that are not owned by root and have the setuid-bit set:
$ grep -E mode=04'[0-9]{3}' /etc/mtree/*|grep -Ev uname=root
Granted, these might also be neglible. I wasn't arguing against this check but
rather wondering whether I understood it correctly.
--
--
Christian