Messages in this thread | | | Subject | Re: [Umbrella-devel] Re: Getting full path from dentry in LSM hooks | Date | Fri, 03 Sep 2004 22:41:35 -0400 | From | Horst von Brand <> |
| |
=?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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |