From: Jesse Pollard <jesse@cats-chateau.net>
To: "Calin A. Culianu" <calin@ajvar.org>, <Valdis.Kletnieks@vt.edu>
Cc: <linux@horizon.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Date: Mon, 5 May 2003 08:35:02 -0500 [thread overview]
Message-ID: <03050508350200.01029@tabby> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0305040301001.6490-100000@rtlab.med.cornell.edu>
On Sunday 04 May 2003 02:03, Calin A. Culianu wrote:
> On Sat, 3 May 2003 Valdis.Kletnieks@vt.edu wrote:
> > On Sat, 03 May 2003 13:19:52 -0000, linux@horizon.com said:
> > > An interesting question arises: is the number of useful interpreter
> > > functions (system, popen, exec*) sufficiently low that they could be
> > > removed from libc.so entirely and only staticly linked, so processes
> > > that didn't use them wouldn't even have them in their address space,
> > > and ones that did would have them at less predictible addresses?
> > >
> > > Right now, I'm thinking only of functions that end up calling execve();
> > > are there any other sufficiently powerful interpreters hiding in common
> > > system libraries? regexec()?
> >
> > This does absolutely nothing to stop an exploit from providing its own
> > inline version of execve(). There's nothing in libc that a process can't
> > do itself, inline.
> >
> > A better bet is using an LSM module that prohibits exec() calls from any
> > unauthorized combinations of running program/user/etc.
>
> Is that practical? I can see how with some daemons it would definitely be
> useful to prohibit exec calls (maybe things like BIND don't need to exec
> anything).. but some daemons do need to exec. An SMTPD may need to exec()
> some helper processes (postfix for instance has a whole slew of helper
> programs it uses).. and things like sshd need to exec a shell, etc..
What you actually would do is have the LSM module turn exec into MAY_EXEC_IF
where the IF is done to match security context information to the binary being
execed. ssh shouldn't exec (well most of the time anyway) a root shell.
Instead it should switch security context, (including a security id and
uid's/gids) first, then exec if the new security context is valid for what is
being execed. (and the new securid is not necessarily selected from kernel
mode - it may depend on network connection + user id/gids requested +
security level permitted)
More complicated, but the full security context being switched to cannot be
selected by the application itself.
> It's still a good idea though, since some daemons don't need to exec,
> ever. I guess this is one extra layer of protection. As Ingo said in his
> announcement, the more layers of protection you have, the better.. and the
> more difficult a cracker's job is.
true.
next prev parent reply other threads:[~2003-05-05 13:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-03 13:19 [Announcement] "Exec Shield", new Linux security feature linux
2003-05-03 23:00 ` Valdis.Kletnieks
2003-05-04 7:03 ` Calin A. Culianu
2003-05-04 8:49 ` Arjan van de Ven
2003-05-05 13:35 ` Jesse Pollard [this message]
2003-05-04 15:24 ` linux
-- strict thread matches above, loose matches on Subject: below --
2003-05-05 7:14 Ingo Molnar
2003-05-04 23:55 Chuck Ebbert
2003-05-05 3:14 ` H. Peter Anvin
2003-05-04 16:20 Yoav Weiss
[not found] <Pine.LNX.4.44.0305040404300.12757-100000@devserv.devel.redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.44.0305040448250.24497-100000@devserv.devel.redhat.com.suse.lists.linux.kernel>
2003-05-04 15:48 ` Andi Kleen
2003-05-04 14:25 Chuck Ebbert
2003-05-04 22:22 ` Richard Henderson
2003-05-05 0:41 ` H. Peter Anvin
2003-05-04 11:19 Yoav Weiss
2003-05-04 13:51 ` Ingo Molnar
2003-05-02 22:46 Chuck Ebbert
[not found] <Pine.LNX.4.44.0305021325130.6565-100000@devserv.devel.redhat.com.suse.lists.linux.kernel>
[not found] ` <200305021829.h42ITclA000178@81-2-122-30.bradfords.org.uk.suse.lists.linux.kernel>
[not found] ` <b8udjm$cgq$1@cesium.transmeta.com.suse.lists.linux.kernel>
2003-05-02 20:51 ` Andi Kleen
2003-05-02 20:56 ` H. Peter Anvin
2003-05-02 21:07 ` Andi Kleen
2003-05-02 21:09 ` H. Peter Anvin
2003-05-02 21:25 ` Andi Kleen
2003-05-02 16:37 Ingo Molnar
2003-05-02 17:05 ` Matthias Andree
2003-05-02 17:12 ` Marc-Christian Petersen
2003-05-02 17:12 ` Davide Libenzi
2003-05-02 17:18 ` Arjan van de Ven
2003-05-02 17:32 ` Ingo Molnar
2003-05-02 18:29 ` John Bradford
2003-05-02 18:32 ` H. Peter Anvin
2003-05-02 19:09 ` David Mosberger
2003-05-02 18:51 ` Davide Libenzi
[not found] ` <20030502172011$0947@gated-at.bofh.it>
2003-05-02 18:17 ` Florian Weimer
2003-05-02 18:29 ` Davide Libenzi
2003-05-02 18:32 ` Florian Weimer
2003-05-02 18:50 ` Davide Libenzi
2003-05-02 21:48 ` Carl-Daniel Hailfinger
2003-05-03 6:52 ` Ingo Molnar
2003-05-03 9:56 ` Carl-Daniel Hailfinger
2003-05-03 12:48 ` Arjan van de Ven
2003-05-04 6:52 ` Calin A. Culianu
2003-05-04 8:10 ` Ingo Molnar
2003-05-04 8:52 ` Ingo Molnar
2003-05-04 15:40 ` Calin A. Culianu
2003-05-04 15:48 ` Sean Neakums
2003-05-04 15:23 ` Calin A. Culianu
2003-05-04 20:07 ` H. Peter Anvin
2003-05-04 20:57 ` Kasper Dupont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03050508350200.01029@tabby \
--to=jesse@cats-chateau.net \
--cc=Valdis.Kletnieks@vt.edu \
--cc=calin@ajvar.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).