[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
David Leonard <firstname.lastname@example.org> 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
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/