From: "Kristian Sørensen" <ks@cs.aau.dk>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: umbrella-devel@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Umbrella-devel] Re: Getting full path from dentry in LSM hooks
Date: Sat, 04 Sep 2004 21:01:18 +0200 [thread overview]
Message-ID: <413A10FE.5050209@cs.aau.dk> (raw)
In-Reply-To: <200409040241.i842fZxa003725@localhost.localdomain>
Horst von Brand wrote:
>>Also simple bufferoverflows in suid-root programs may be avoided.
>
>
> How?
You can (naturally) not avoid the attack and thereby the process from
crashing - but you can avoid the effects of it. E.g. if you restrict the
suid-root process form spawning new processes, it would not be able to
spawn a root shell, programs liks passwd and cdrecord would be good
candidates to this restriction.
>> The
>>simple way would to set the restriction "no fork", and thus if an
>>attacker tries to fork a (root) shell, this would be denied.
>
>
> A simple exec(2) will do. Or overwriting a file. Or... If you restrict all
> potentially dangerous operations, you have nothing useful left.
>
>
>> Another way
>>could be to heavily restrict access to the filesystem. If the program is
>>restricted from /var, the root shell spawned by the attack would not
>>have access either. (restrictions are enherited from parent to children).
>
>
> Just delete /var. Oops, it is there for a purpose...
Sure... but not all programs really need access to this. My calendar on
my PDA for one do not. It (restricting /var) was, as I hope you
guessed?, an example!
A cool thing is also, that if you restrict the init process from
accessing a secific directory, then all processes in the system will be
restricted from this. This will be utilized by Umbrella, to introduce
signed files (public key cryptography). The area of the public keys will
be protected by the kernel - simply by restricting Init from this location.
KS.
next prev parent reply other threads:[~2004-09-04 19:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 12:12 Getting full path from dentry in LSM hooks Kristian Sørensen
2004-09-03 12:32 ` Christoph Hellwig
2004-09-03 12:38 ` [Umbrella-devel] " Kristian Sørensen
2004-09-03 13:04 ` Christoph Hellwig
2004-09-03 13:20 ` Kristian Sørensen
2004-09-03 14:01 ` Christoph Hellwig
2004-09-03 19:54 ` Kristian Sørensen
2004-09-04 11:09 ` Christoph Hellwig
2004-09-04 18:52 ` Kristian Sørensen
2004-09-03 15:38 ` Stephen Smalley
2004-09-03 12:43 ` Andrea Arcangeli
2004-09-03 14:14 ` Alan Cox
2004-09-03 20:05 ` [Umbrella-devel] " Kristian Sørensen
2004-09-03 20:39 ` Valdis.Kletnieks
2004-09-04 9:06 ` Kristian Sørensen
2004-09-04 10:50 ` Emmanuel Fleury
2004-09-07 14:19 ` Kristian Sørensen
2004-09-04 2:41 ` Horst von Brand
2004-09-04 19:01 ` Kristian Sørensen [this message]
2004-09-04 19:06 ` Kristian Sørensen
2004-09-04 16:56 ` Alan Cox
2004-09-04 18:47 ` Kristian Sørensen
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=413A10FE.5050209@cs.aau.dk \
--to=ks@cs.aau.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=umbrella-devel@lists.sourceforge.net \
--cc=vonbrand@inf.utfsm.cl \
/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