=?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= <[email protected]> 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
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.
Just forgot something:
Horst von Brand wrote:
>> 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.
You misunderstood this. The restrictions are introduced by a "restricted
fork", to which you specify the restrictions the mext process should
have + those inherited from the parent. So if you execute an attachment
from the thread that views the email, THIS should be restricted from
e.g. addressbook and network.
Anyway, when you answer a message - in most cases you put the message in
an "outbox", which the main thread of the mail program sends, when told
to, and as the main thread is not restricted from the network
(supprise!) it will succeed in sending the mails.