public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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