mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horst von Brand <vonbrand@inf.utfsm.cl>
To: "Kristian Sørensen" <ks@cs.aau.dk>
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: Fri, 03 Sep 2004 22:41:35 -0400	[thread overview]
Message-ID: <200409040241.i842fZxa003725@localhost.localdomain> (raw)
In-Reply-To: Message from =?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= <ks@cs.aau.dk>  of "Fri, 03 Sep 2004 22:05:03 +0200." <4138CE6F.10501@cs.aau.dk>

=?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= <ks@cs.aau.dk> said:

[...]

> Umbrella is mostly designed for embedded systems (where selinux is 
> overkill) and also it is very easy to understand. Most restrictions will 
> be made to e.g. stop viruses from spreading, and it is quite easy, yet 
> very effective:

> If an email client receives an malformed email (like the countless 
> attacks on outlook), a simple restriction could be for the process 
> handeling the mail would be "$HOME/.addressbook",

A mail handling process with the adressbook off-limit sounds _real_ useful.

>                                                   furthermore, you could 
> specify that attachments executed _from_ the emailprogram would not have 
> access to the network.

I.e., no child of the email program could access the network, not even to
answer a message. Sounds restrictive.

>                        Thus the virus cannot find mail addresses to send 
> itself to - and it cannot even get network access. Simple and effective.

Right.

> Also simple bufferoverflows in suid-root programs may be avoided.

How?

>                                                                   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...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

  parent reply	other threads:[~2004-09-04  3:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-03 12:12 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 [this message]
2004-09-04 19:01       ` Kristian Sørensen
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=200409040241.i842fZxa003725@localhost.localdomain \
    --to=vonbrand@inf.utfsm.cl \
    --cc=ks@cs.aau.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=umbrella-devel@lists.sourceforge.net \
    /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

all inboxes | Powered by JetHome®