[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: securelevel=3



David Leonard <leonard@csee.uq.edu.au> writes:

> perhaps we should have a 64 bit 'securemask' with each bit
> representing some feature or another ;-)

The general idea of locking something down in the kernel could be
extended further.

It might be useful to have some sort of securemask on per process
basis (with a special system call that can _set_ some bits of
it--there should be no way of clearing a bit, and it should be
inherited by children).

Possible applications that I am seeing:

* Forbid (and log) all attempts to *fork();
* Forbid (and log) all attempts to exec*();
* Forbid (and log) all attempts to setsockopt(), connect(), and sendto();
* Forbid (and log) all attempts to setsockopt(), accept(), and recvfrom();
* Change open() semantics so that open does not follow symbolic links;
* Change open() semantics so that files can be opened only for 
  (a) reading; (b) appending; (c) with O_EXCL|O_TRUNC flags.

This mechanism can be used for two things:

1. When combined with chroot() (if appropriate) this could be used as
a safety net to put in the beginning of all security-critical programs
(setuid/setgid or talking to the network).

2. If the flags are choosen carefully, secure restricted environments
(e.g., menu-based guest users) can be created.

-- 
Stanislav Shalunov	System Administrator, MCCME (http://www.mccme.ru/)
Hiroshima 45--Chernobyl' 86--Windows 95   |   Spam?  http://www.cauce.org/