Re: [Umbrella-devel] Re: Getting full path from dentry in LSM hooks

From: Horst von Brand
Date: Fri Sep 03 2004 - 22:25:19 EST


=?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= <ks@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/