Re: kernel stack challenge

[Valdis . Kletnieks]

On Mon, 05 Apr 2004 10:59:40 PDT, Sergiy Lozovsky said:

> 1. Give system administrator possibility to change
> security policy easy enough without C programminig
> inside the kernel (we should not expect system
> administartor to be a kernel guru). Language of higher
> lavel make code more compact (C - is too low level,
> that's why people use PERL for example or LISP). Lisp
> was chosen because of very compact VM - around 100K.

Didn't seem to slow the SELinux crowd down any...

You may not need the exact SELinux config language, but it does address the
issue of making something fairly easy for the sysadmin to write while not
requiring a large interpreter in the kernel (the kernel side of the selinuxfs
pseudo-filesystem is all of 14K, the loadpolicy is about a 4K binary and a 60K
shared library, and the policy compiler is about 100K and the shared lib).

So you're including a much bigger interface for little gain.  The total
footprint of the two solutions is about the same, but SELinux the vast majority
of it is in userspace, and only costs you when you're actually compiling/
loading a new policy, whereas yours takes up 100K of kernel space all the
time....

> 2. Protect system from bugs in security policy created
> by system administrator (user). LISP interpreter is a
> LISP Virtual Machine (as Java VM). So all bugs are
> incapsulated and don't affect kernel. Even severe bugs
> in this LISP kernel module can cause termination of
> user space application only (except of stack overflow
> - which I can address). LISP error message will be
> printed in the kernel log.

If you think that "all bugs are encapsulated" actually means anything in the
context of the Linux kernel, you're in for a very big surprise.

For example - your Lisp error messages go through the kernel log, so you're
using printk() and friends.  Note that it *is* possible for a buggy call to
printk() to cause problems for the kernel.

Attachment: pgp00000.pgp
Description: PGP signature