Hi,
I have a stack hungry code in the kernel. It hits the
end of stack from time to time. I wrote function to
which I pass pointers to function and memory area
which should be used as stack for function execution.
(I just load pointer to new stack area into esp
register). This function works just fine in user space
and memory area provided by me is used as stack.
This function doesn't work in the kernel (system hungs
instantly when my function is called). Does antbody
have any idea what the reason can be? Some special
alignment? Special memory segment? In what direction
should I look?
(sure I tried some magic with alignment like -
__attribute__ ((aligned (8192))) - no any effect)
(there was some patch to increase stack size
kernelwide, but I don't want to affect all the
system).
Thanks,
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky <[email protected]> writes:
> This function doesn't work in the kernel (system hungs
> instantly when my function is called). Does antbody
> have any idea what the reason can be? Some special
> alignment? Special memory segment? In what direction
> should I look?
The kernel puts some data about the current task at the bottom
of the stack and accesses that by referencing the stack pointer
in "current". This is even used by interrupts.
-Andi
Thanks, Andi. That can be the case. Bad thing is that
stack size is hardcoded all over the kernel.
I wonder how it is possible to access task struct
having current stack pointer. %esp points at the
middle of the stack (when we are in the kernel) when
interrupt occures.
Serge.
--- Andi Kleen <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> writes:
>
> > This function doesn't work in the kernel (system
> hungs
> > instantly when my function is called). Does
> antbody
> > have any idea what the reason can be? Some special
> > alignment? Special memory segment? In what
> direction
> > should I look?
>
> The kernel puts some data about the current task at
> the bottom
> of the stack and accesses that by referencing the
> stack pointer
> in "current". This is even used by interrupts.
>
> -Andi
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Sun, Apr 04, 2004 at 11:24:38AM -0700, Sergiy Lozovsky wrote:
> I wonder how it is possible to access task struct
> having current stack pointer. %esp points at the
> middle of the stack (when we are in the kernel) when
> interrupt occures.
Look at the curren()t and get_current() macros. Basically, the stack
is page aligned, so with the proper masking of %esp you can get to the
bottom of the stack.
See http://www.kernelnewbies.org/faq/, "how does get_current work?".
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
Sergiy Lozovsky wrote:
> Hi,
>
> I have a stack hungry code in the kernel. It hits the
> end of stack from time to time. I wrote function to
> which I pass pointers to function and memory area
> which should be used as stack for function execution.
> (I just load pointer to new stack area into esp
> register). This function works just fine in user space
> and memory area provided by me is used as stack.
>
> This function doesn't work in the kernel (system hungs
> instantly when my function is called). Does antbody
> have any idea what the reason can be? Some special
> alignment? Special memory segment? In what direction
> should I look?
>
> (sure I tried some magic with alignment like -
> __attribute__ ((aligned (8192))) - no any effect)
>
> (there was some patch to increase stack size
> kernelwide, but I don't want to affect all the
> system).
You aren't supposed to need much stack for anything in the kernel.
Consider rewriting your function to use allocated
memory instead of stack, this isn't all that hard.
Helge Hafting
> Consider rewriting your function to use allocated
> memory instead of stack, this isn't all that hard.
I put LISP interpreter inside the Kernel -
http://vxe.quercitron.com
It works, but it use a lot of stack memory. It's
impossible to rewrite it easily, though I'll
investigate why exactly it uses so much of stack
memory (though it's nature of LISP). There are no
serious kernel memory allocation (as of my interpreter
code review, only function calls; recursions in LISP
application itself are eliminated for sure), but I'll
trace stack usage more thouroughly.
Serge.
--- Helge Hafting <[email protected]> wrote:
> Sergiy Lozovsky wrote:
> > Hi,
> >
> > I have a stack hungry code in the kernel. It hits
> the
> > end of stack from time to time. I wrote function
> to
> > which I pass pointers to function and memory area
> > which should be used as stack for function
> execution.
> > (I just load pointer to new stack area into esp
> > register). This function works just fine in user
> space
> > and memory area provided by me is used as stack.
> >
> > This function doesn't work in the kernel (system
> hungs
> > instantly when my function is called). Does
> antbody
> > have any idea what the reason can be? Some special
> > alignment? Special memory segment? In what
> direction
> > should I look?
> >
> > (sure I tried some magic with alignment like -
> > __attribute__ ((aligned (8192))) - no any effect)
> >
> > (there was some patch to increase stack size
> > kernelwide, but I don't want to affect all the
> > system).
>
>
> You aren't supposed to need much stack for anything
> in the kernel.
> Consider rewriting your function to use allocated
> memory instead of stack, this isn't all that hard.
>
> Helge Hafting
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky wrote:
>
> I put LISP interpreter inside the Kernel -
I'm dying to know why you need a LISP interpreter inside the kernel.
--- Timothy Miller <[email protected]> wrote:
>
>
> Sergiy Lozovsky wrote:
>
> >
> > I put LISP interpreter inside the Kernel -
>
>
>
> I'm dying to know why you need a LISP interpreter
> inside the kernel.
It is explained at my project home page -
http://vxe.quercitron.com
Basically there are two reasons.
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.
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.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
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.
>>>>> "Sergiy" == Sergiy Lozovsky <[email protected]> writes:
Sergiy> Basically there are two reasons.
Sergiy> 1. Give system administrator possibility to change security
Sergiy> policy easy enough without C programminig inside the kernel
Sergiy> (we should not expect system administartor to be a kernel
Sergiy> guru). Language of higher lavel make code more compact (C - is
Sergiy> too low level, that's why people use PERL for example or
Sergiy> LISP). Lisp was chosen because of very compact VM - around
Sergiy> 100K.
Why in god's name does this need to be in the kernel? This is purely
a userspace issue, and the tool for managing the security policy
should be completely in userspace.
Under this design, /bin/ls would be a kernel module, and not a
userspace tool!
If you ever want to even think about getting this project into the
kernel, you'll have to re-design what you're doing here, since there's
absolutely no need for anything like this in the kernel.
Sergiy> 2. Protect system from bugs in security policy created by
Sergiy> system administrator (user).
C'mon, GIGO will kill you from user space or from kernel space. What
makes you think LISP will protect you?
Sergiy> LISP interpreter is a LISP Virtual Machine (as Java VM). So
Sergiy> all bugs are incapsulated and don't affect kernel.
Then *WHY* does the LISP interpreter need to be in the kernel in the
first place? Hint, you just said you wanted to protect the kernel...
Sergiy> Even severe bugs in this LISP kernel module can cause
Sergiy> termination of user space application only (except of stack
Sergiy> overflow - which I can address). LISP error message will be
Sergiy> printed in the kernel log.
Hah! You just gave the number one reason why you don't want or need a
LISP interpreter in the kernel yourself.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
Sergiy Lozovsky wrote:
>
> 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.
And you expect your sysadmins to know LISP? I would hardly think of
LISP as any kind of simplification to anything.
I mean, I like the language and all, but it is in no way "simpler" than
C and it's definately not appropriate for in-kernel stuff.
>
> 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.
In theory, we could develop the kernel in a language that does all sorts
of protection, garbage collection, run-time checking, etc. Kernel
developers choose not to because the performance hit would be HORRIBLE.
Now... that doesn't mean you can't do kernel-level stuff in LISP. You
just don't do it _in_ the kernel. Given the absolutely MASSIVE overhead
you're already incurring by using a LISP interpreter, having to
context-switch into user space won't hurt in the least. So, what you do
is have a C-based stub in the kernel which passes stuff off to the
user-space LISP daemon which calls back into the kernel for accessing
devices, etc.
THAT would be a much better way of doing this.
[email protected] wrote:
>
> 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....
>
The key concept here is "in userspace".
--- John Stoffel <[email protected]> wrote:
> >>>>> "Sergiy" == Sergiy Lozovsky
> <[email protected]> writes:
>
> Sergiy> Basically there are two reasons.
>
> Sergiy> 1. Give system administrator possibility to
> change security
> Sergiy> policy easy enough without C programminig
> inside the kernel
> Sergiy> (we should not expect system administartor
> to be a kernel
> Sergiy> guru). Language of higher lavel make code
> more compact (C - is
> Sergiy> too low level, that's why people use PERL
> for example or
> Sergiy> LISP). Lisp was chosen because of very
> compact VM - around
> Sergiy> 100K.
>
> Why in god's name does this need to be in the
> kernel? This is purely
> a userspace issue, and the tool for managing the
> security policy
> should be completely in userspace.
UNIX security policy is already implemented in the
Kernel, or should we move checking of root priveleges
and file permissions to the userspace? I just extended
existing security features.
> Under this design, /bin/ls would be a kernel module,
> and not a
> userspace tool!
No :-) What you suggest is kernel should receive
system call from user space. Instead of handling it -
kernel should forward it back to userspace, than it
should be forwarded back to the kernel. Looks not very
nice to me. Why not to handle security policy inside
the kernel as it is done for the file permissions and
root priveleges?
> Sergiy> 2. Protect system from bugs in security
> policy created by
> Sergiy> system administrator (user).
>
> C'mon, GIGO will kill you from user space or from
> kernel space. What
> makes you think LISP will protect you?
>
> Sergiy> LISP interpreter is a LISP Virtual Machine
> (as Java VM). So
> Sergiy> all bugs are incapsulated and don't affect
> kernel.
>
> Then *WHY* does the LISP interpreter need to be in
> the kernel in the
> first place? Hint, you just said you wanted to
> protect the kernel...
All LISP errors are incapsulated within LISP VM.
> Sergiy> Even severe bugs in this LISP kernel module
> can cause
> Sergiy> termination of user space application only
> (except of stack
> Sergiy> overflow - which I can address). LISP error
> message will be
> Sergiy> printed in the kernel log.
>
> Hah! You just gave the number one reason why you
> don't want or need a
> LISP interpreter in the kernel yourself.
What reason you have in mind? All available security
models have predefined stack usage, so it is
completely safe to use them.
For those who want to define their security model (not
security policy!) - they shoud respect stack
limitations for now. Which sounds reasonable. Using
existing security models it is impossible to cause
stack overflow. (depth of subroutine calls is
constant).
Serge.
> John
> John Stoffel - Senior Unix Systems Administrator
> - Lucent Technologies
> [email protected] - http://www.lucent.com -
978-952-7548
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- [email protected] wrote:
> On Mon, 05 Apr 2004 13:33:10 PDT, you said:
>
> > I don't know how it is possible (if it is - it's
> easy
> > to fix). All LISP print functions print
> information
> > into the buffer of limited size. (LISP program has
> no
> > access to the format or buffer length arguments of
> > snprintf). When buffer is full or string has an \n
> at
> > the end - VM calls printk.
>
> That's how it's *supposed* to work when everything
> is working *correctly*.
>
> Now re-do your example, and assume there's a *BUG*
> in the VM. For instance,
Here is a main idea. I can put a lot of effort to
debug VM once. I (and others) are not destined to do
such kind of debugging (with C inside the kernel)
after that. It's like with JAVA VM - it's hard to
debug VM, but it should be done once - after that JAVA
program can't use a pointer to a nonallocated memory.
Those who continue to use C - should be careful with
pointersin each program.
> what happens if there's a fencepost error on "buffer
> is full"? All that takes
> is one line that says 'if (ptr > bufsize)' rather
> than 'if (ptr >= bufsize)'.
>
> Yes, proper encapsulation *helps*. But it's
Exactly. :-) i'm not claiming that I solve all
problems. But this technology helps to make
development of some kernel parts easier. Encapsulation
helps and you can easily debug LISP program in the
userspace before loading it into the kernel.
No matter what particular LISP program does - it can't
crash the kernel - C code can do that easily.
Serge.
> certainly *NOT* any sort of
> guarantee that *all* bugs will be stopped. For
> comparison, read up on the Java
> VM - although it does a very good job of sandboxing
> a Java program, there
> *have* been bugs and exploits found over the
> years....
>
>
> ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky wrote:
>
>
> All LISP errors are incapsulated within LISP VM.
>
A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER*
*SUFFOCATE* ... thing which SHOULD NEVER be in the kernel.
If you want to use a more abstract language for describing kernel
security policies, fine. Just don't use LISP.
The right way to do it is this:
- A user space interpreter reads text-based config files and converts
them into a compact, easy-to-interpret code used by the kernel.
- A VERY TINY kernel component is fed the security policy and executes it.
Move as much of the processing as reasonable into user space. It's
absolutely unnecessary to have the parser into the kernel, because
parsing of the config files is done only when the ASCII text version
changes.
It's absolutely unnecessary to have something as complex as LISP to
interpret it, when something simple and compact could do just as well.
Why do you choose LISP? Don't you want to use a language that sysadmins
will actually KNOW?
On Mon, 5 Apr 2004, Timothy Miller wrote:
>Sergiy Lozovsky wrote:
>
>>
>>
>> All LISP errors are incapsulated within LISP VM.
>>
>
>
>A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER*
>*SUFFOCATE* ... thing which SHOULD NEVER be in the kernel.
Ah your thinking of the days when 1 meg of memory was a lot and LISP was
considered huge.. With 4 gigs of memory today, it shouldnt be a problem
:). Actually a LISP vm can fit into a small amount of memory depending
on what you want it to do...
I think in the end, this is a 'When all you know is to hammer,
everything is a nail.' They know LISP.
>Why do you choose LISP? Don't you want to use a language that sysadmins
>will actually KNOW?
Because how else can you get emacs to the only thing to run?
--
Stephen John Smoogen [email protected]
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --
--- Timothy Miller <[email protected]> wrote:
>
>
> Sergiy Lozovsky wrote:
>
> >
> >
> > All LISP errors are incapsulated within LISP VM.
> >
>
>
> A LISP VM is a big, giant, bloated.... *CHOKE*
> *COUGH* *SPUTTER*
> *SUFFOCATE* ... thing which SHOULD NEVER be in the
> kernel.
It is a smallest interpreter (of all purpose language)
I was able to find. My guess is that you refer to the
Common Lisp. it is huge and I don't use it.
>
> If you want to use a more abstract language for
> describing kernel
> security policies, fine. Just don't use LISP.
Point me to ANy langage with VM around 100K.
> The right way to do it is this:
>
> - A user space interpreter reads text-based config
> files and converts
> them into a compact, easy-to-interpret code used by
> the kernel.
>
> - A VERY TINY kernel component is fed the security
> policy and executes it.
it is exactly the way it is implemented. Not everyone
need to create their own security model (that VERY
TINY kernel component you refer to). But even for
those who want to modify or create their own VERY TINY
kernel component - they don't need to do that in C and
debug it in th kernel crashing it.
>
> Move as much of the processing as reasonable into
> user space. It's
> absolutely unnecessary to have the parser into the
> kernel, because
> parsing of the config files is done only when the
> ASCII text version
> changes.
>
> It's absolutely unnecessary to have something as
> complex as LISP to
> interpret it, when something simple and compact
> could do just as well.
>
> Why do you choose LISP? Don't you want to use a
> language that sysadmins
> will actually KNOW?
It was is) the smallest VM I know of.
99% of sysadmins don't need to create their own
security models. Security polices are created with web
interface very close to the way you described. So
sysadmin don't need to know anything about LISP (to
use predefined security models).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Chris Wright <[email protected]> wrote:
> * Sergiy Lozovsky ([email protected]) wrote:
> > No :-) What you suggest is kernel should receive
> > system call from user space. Instead of handling
> it -
> > kernel should forward it back to userspace, than
> it
> > should be forwarded back to the kernel. Looks not
> very
> > nice to me. Why not to handle security policy
> inside
> > the kernel as it is done for the file permissions
> and
> > root priveleges?
>
> All this can be done w/out having a LISP
> interpretter coming along for the
> ride, that's the point of the other posters. With
> LSM you have a
> framework for implementing your own security model
> and enforcing your own
> policies.
LSM use another way of doing similar things :-) I'm
not sure that it is nice to forward system calls back
to userspace where they came from in the first place
:-) VXE use high level language to create security
models.
And what are the problems with technology used by VXE?
File permissions are checked in the kernel and
everybody are happy with that. VXE just extends
security features already available in the kernel.
There is a historic part to all that, too - VXE was
created (1999) before SELinux was available.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Mon, 2004-04-05 at 14:30, Sergiy Lozovsky wrote:
> --- Timothy Miller <[email protected]> wrote:
> >
> >
> > Sergiy Lozovsky wrote:
> >
> > >
> > >
> > > All LISP errors are incapsulated within LISP VM.
> > >
> >
> >
> > A LISP VM is a big, giant, bloated.... *CHOKE*
> > *COUGH* *SPUTTER*
> > *SUFFOCATE* ... thing which SHOULD NEVER be in the
> > kernel.
>
> It is a smallest interpreter (of all purpose language)
> I was able to find. My guess is that you refer to the
> Common Lisp. it is huge and I don't use it.
>
How about BF? ;)
I would think something like forth might be a better fit then lisp.
> >
> > If you want to use a more abstract language for
> > describing kernel
> > security policies, fine. Just don't use LISP.
>
> Point me to ANy langage with VM around 100K.
>
> > The right way to do it is this:
> >
> > - A user space interpreter reads text-based config
> > files and converts
> > them into a compact, easy-to-interpret code used by
> > the kernel.
> >
> > - A VERY TINY kernel component is fed the security
> > policy and executes it.
>
> it is exactly the way it is implemented. Not everyone
> need to create their own security model (that VERY
> TINY kernel component you refer to). But even for
> those who want to modify or create their own VERY TINY
> kernel component - they don't need to do that in C and
> debug it in th kernel crashing it.
>
> >
> > Move as much of the processing as reasonable into
> > user space. It's
> > absolutely unnecessary to have the parser into the
> > kernel, because
> > parsing of the config files is done only when the
> > ASCII text version
> > changes.
> >
> > It's absolutely unnecessary to have something as
> > complex as LISP to
> > interpret it, when something simple and compact
> > could do just as well.
> >
> > Why do you choose LISP? Don't you want to use a
> > language that sysadmins
> > will actually KNOW?
>
> It was is) the smallest VM I know of.
>
> 99% of sysadmins don't need to create their own
> security models. Security polices are created with web
> interface very close to the way you described. So
> sysadmin don't need to know anything about LISP (to
> use predefined security models).
>
> Serge.
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
* Sergiy Lozovsky ([email protected]) wrote:
> LSM use another way of doing similar things :-) I'm
> not sure that it is nice to forward system calls back
> to userspace where they came from in the first place
> :-) VXE use high level language to create security
> models.
There's no requirement in LSM to forward syscalls back to userspace for
access control check. At any rate, seems you like your solution, just
wanted to make sure you were aware of alternatives.
> And what are the problems with technology used by VXE?
It's the LISP interpreter that's problematic. As you've already seen
with the kernel stack limitations.
> File permissions are checked in the kernel and
> everybody are happy with that. VXE just extends
> security features already available in the kernel.
And LSM checks are done in kernel.
> There is a historic part to all that, too - VXE was
> created (1999) before SELinux was available.
Ah, the real truth ;-)
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Monday 05 April 2004 23:30, Sergiy Lozovsky wrote:
> Point me to ANy langage with VM around 100K.
There is a Java VM (lejos) f?r the Lego Mindstorms robot. The hardware
has 32K memory.
-- robin
Stephen Smoogen wrote:
> On Mon, 5 Apr 2004, Timothy Miller wrote:
>
>
>>Sergiy Lozovsky wrote:
>>
>>
>>>
>>>All LISP errors are incapsulated within LISP VM.
>>>
>>
>>
>>A LISP VM is a big, giant, bloated.... *CHOKE* *COUGH* *SPUTTER*
>>*SUFFOCATE* ... thing which SHOULD NEVER be in the kernel.
>
>
> Ah your thinking of the days when 1 meg of memory was a lot and LISP was
> considered huge.. With 4 gigs of memory today, it shouldnt be a problem
> :). Actually a LISP vm can fit into a small amount of memory depending
> on what you want it to do...
People complained about having Athlon-specific fixes in all x86 kernels
because of the extra few hundred bytes it would waste for a Pentium kernel.
What makes you think people would accept a LISP interpreter?
Sergiy Lozovsky wrote:
> --- Timothy Miller <[email protected]> wrote:
>
>>
>>Sergiy Lozovsky wrote:
>>
>>
>>>
>>>All LISP errors are incapsulated within LISP VM.
>>>
>>
>>
>>A LISP VM is a big, giant, bloated.... *CHOKE*
>>*COUGH* *SPUTTER*
>>*SUFFOCATE* ... thing which SHOULD NEVER be in the
>>kernel.
>
>
> It is a smallest interpreter (of all purpose language)
> I was able to find. My guess is that you refer to the
> Common Lisp. it is huge and I don't use it.
Did you separate out the parser out into a user-space daemon?
Also, if you want a regular programming language with an extremely small
interpreter, try Forth.
Learning Forth should be at LEAST as much fun as learning LISP.
>
>
>>If you want to use a more abstract language for
>>describing kernel
>>security policies, fine. Just don't use LISP.
>
>
> Point me to ANy langage with VM around 100K.
I bet a Forth interpreter would be smaller.
And for something specialized like security policy, you could probably
develop your own language and interpreter for it, and it would be
smaller (and faster) still.
>
>
>>The right way to do it is this:
>>
>>- A user space interpreter reads text-based config
>>files and converts
>>them into a compact, easy-to-interpret code used by
>>the kernel.
>>
>>- A VERY TINY kernel component is fed the security
>>policy and executes it.
>
>
> it is exactly the way it is implemented. Not everyone
> need to create their own security model (that VERY
> TINY kernel component you refer to). But even for
> those who want to modify or create their own VERY TINY
> kernel component - they don't need to do that in C and
> debug it in th kernel crashing it.
You misunderstand. When I say "VERY TINY kernel component", I'm
referring to the interpreter. Done properly, the pcode for the policy
itself would be microscopic.
>
>
>>Move as much of the processing as reasonable into
>>user space. It's
>>absolutely unnecessary to have the parser into the
>>kernel, because
>>parsing of the config files is done only when the
>>ASCII text version
>>changes.
>>
>>It's absolutely unnecessary to have something as
>>complex as LISP to
>>interpret it, when something simple and compact
>>could do just as well.
>>
>>Why do you choose LISP? Don't you want to use a
>>language that sysadmins
>>will actually KNOW?
>
>
> It was is) the smallest VM I know of.
Forth.
Sergiy Lozovsky wrote:
>
>
> LSM use another way of doing similar things :-) I'm
> not sure that it is nice to forward system calls back
> to userspace where they came from in the first place
> :-) VXE use high level language to create security
> models.
>
"Kernel space -> user space -> kernel space" is nothing compared to the
overhead of a LISP interpreter.
Doing interpretation of LISP is a monster compared to some piddly
context switches.
--- Horst von Brand <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
>
> [LISP inside the kernel?!]
>
> > Basically there are two reasons.
> >
> > 1. Give system administrator possibility to change
> > security policy easy enough
>
> SELinux
To create a new 'security model' one should write a C
program within Selinux user space security server.
People like to use higher level languages.
> > without C programminig
> > inside the kernel (we should not expect system
> > administartor to be a kernel guru).
>
> As 97.572% of the job has to be done in userland
> anyway, place your
> checks/high-level language/GUI frobnitzer in there
> at will. Compile to a
> compact, easy-to-handle, digitally signed, binary
> blob and stuff _that_
> into the kernel as needed.
I'm not ready to put a binary compiled with Common
Lisp or PERL (if it exists) compilers into the kernel.
At the same time I want people to benefit from using
high level langages (even kernel gurus don't use
Assembler all the time, higher level languages is
easier to use and less lines of code to write).
.....
> > 2. Protect system from bugs in security policy
> created
> > by system administrator (user).
>
> Sounds like you are demanding a solution to Turing's
> test here... and also
> to the halting problem.
I didn't claim that I solve all problems on earth :-)
What I can claim:
1. Some kernel parts can be developed with language of
higher level than C.
2. Problems with such parts can be to some extent be
encapsulated within VM (no, it's not 100% fool prof
for sure), but it helps.
3. Code can be easily debugged in the user space
(running with user space VM) and used in the kernel
after that.
> > LISP interpreter
> is a
> > LISP Virtual Machine (as Java VM).
>
> So what? If the policy just leaves out everybody, or
> lets anybody fool
> around with the hardware, you are royally screwed in
> any case.
I didn't get the question.
> > 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 it is running in userspace, why do you place the
> interpreter in the kernel?
LISP code is located in the kernel. Application issues
a system call LISP program checks arguments of this
call. If LISP program fails (crashes) - VM will return
default value which is EACCESS, so application will
get 'access denied'. (and will fail, probably).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
* Sergiy Lozovsky ([email protected]) wrote:
> No :-) What you suggest is kernel should receive
> system call from user space. Instead of handling it -
> kernel should forward it back to userspace, than it
> should be forwarded back to the kernel. Looks not very
> nice to me. Why not to handle security policy inside
> the kernel as it is done for the file permissions and
> root priveleges?
All this can be done w/out having a LISP interpretter coming along for the
ride, that's the point of the other posters. With LSM you have a
framework for implementing your own security model and enforcing your own
policies.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--- Robin Rosenberg <[email protected]>
wrote:
> On Monday 05 April 2004 23:30, Sergiy Lozovsky
> wrote:
> > Point me to ANy langage with VM around 100K.
>
> There is a Java VM (lejos) f?r the Lego Mindstorms
> robot. The hardware
> has 32K memory.
Is it Free and Open Source? Where can I get it if it
is?
(I don't want to start Holly War :-) but I think, that
Java is lower lavel than C, I recognize, that I can be
wrong)
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
I wanted something higher level than C. Forth looks
like C to me. I wanted something with build in support
of complex structures and automatic memory management.
I see no reason to replace one C with another.
> Did you separate out the parser out into a
> user-space daemon?
I didn't. It's possible optimization, but it will not
give any good. The syntax of LISP is much simpler than
Forth (this another reason I chose LISP :-), so parser
is very small.
> >>Why do you choose LISP? Don't you want to use a
> >>language that sysadmins
> >>will actually KNOW?
At the start of the project I tried to design my own
small language (just for security system). At this
point I understood that I didn't want to settle with
anything less than universal language. The idea to
invent some language and write VM for it didn't appeal
to me. I wanted to make a security system, not a new
language. I wanted language to be as simple as
possible. LISP had the simpliest syntax from all
languages. So I found small lisp interpreter (kind of
real time - without garbage collector which stops
execution) added string and bit operations, modified
it to be placed in the kernel.
Ok, it was my marketing claim about sysadmins :-)
Sysadmins use web interface to configure polices and
don't deal with LISP at all.
LISP is for those who want to change security Models
only.
Serge.
--- Timothy Miller <[email protected]> wrote:
>
>
> Sergiy Lozovsky wrote:
> > --- Timothy Miller <[email protected]> wrote:
> >
> >>
> >>Sergiy Lozovsky wrote:
> >>
> >>
> >>>
> >>>All LISP errors are incapsulated within LISP VM.
> >>>
> >>
> >>
> >>A LISP VM is a big, giant, bloated.... *CHOKE*
> >>*COUGH* *SPUTTER*
> >>*SUFFOCATE* ... thing which SHOULD NEVER be in the
> >>kernel.
> >
> >
> > It is a smallest interpreter (of all purpose
> language)
> > I was able to find. My guess is that you refer to
> the
> > Common Lisp. it is huge and I don't use it.
>
> Did you separate out the parser out into a
> user-space daemon?
>
> Also, if you want a regular programming language
> with an extremely small
> interpreter, try Forth.
>
> Learning Forth should be at LEAST as much fun as
> learning LISP.
>
> >
> >
> >>If you want to use a more abstract language for
> >>describing kernel
> >>security policies, fine. Just don't use LISP.
> >
> >
> > Point me to ANy langage with VM around 100K.
>
> I bet a Forth interpreter would be smaller.
>
> And for something specialized like security policy,
> you could probably
> develop your own language and interpreter for it,
> and it would be
> smaller (and faster) still.
>
> >
> >
> >>The right way to do it is this:
> >>
> >>- A user space interpreter reads text-based config
> >>files and converts
> >>them into a compact, easy-to-interpret code used
> by
> >>the kernel.
> >>
> >>- A VERY TINY kernel component is fed the security
> >>policy and executes it.
> >
> >
> > it is exactly the way it is implemented. Not
> everyone
> > need to create their own security model (that VERY
> > TINY kernel component you refer to). But even for
> > those who want to modify or create their own VERY
> TINY
> > kernel component - they don't need to do that in C
> and
> > debug it in th kernel crashing it.
>
> You misunderstand. When I say "VERY TINY kernel
> component", I'm
> referring to the interpreter. Done properly, the
> pcode for the policy
> itself would be microscopic.
>
> >
> >
> >>Move as much of the processing as reasonable into
> >>user space. It's
> >>absolutely unnecessary to have the parser into the
> >>kernel, because
> >>parsing of the config files is done only when the
> >>ASCII text version
> >>changes.
> >>
> >>It's absolutely unnecessary to have something as
> >>complex as LISP to
> >>interpret it, when something simple and compact
> >>could do just as well.
> >>
> >>Why do you choose LISP? Don't you want to use a
> >>language that sysadmins
> >>will actually KNOW?
> >
> >
> > It was is) the smallest VM I know of.
>
> Forth.
>
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Timothy Miller <[email protected]> wrote:
>
>
> Sergiy Lozovsky wrote:
>
> >
> >
> > LSM use another way of doing similar things :-)
> I'm
> > not sure that it is nice to forward system calls
> back
> > to userspace where they came from in the first
> place
> > :-) VXE use high level language to create security
> > models.
> >
>
> "Kernel space -> user space -> kernel space" is
To be more precise "user space -> kernel space -> user
space -> kernel space -> user space"
against ordinary "user space -> kernel space -> user
space"
So, what happens - task makes system calls and blocks;
request goes to a user space security server. Will it
process request right away? No, it will wait for
scheduler to chose it for execution. Ok server got CPU
and returns results to the kernel. Will initial task
continue? No, it will wait for be chosen by scheduler.
This is what I call overhead (though i understand,
that can be wrong). My system (VXE) doesn't involve
scheduler at all.
So we should not just look into length of this chain
at the picture. - "user space -> kernel space -> user
space -> kernel space -> user space" - we should
remember that it involves to mandatory task switches
to accomplish jus one system call.
> nothing compared to the
> overhead of a LISP interpreter.
LISP code, is very small actually. And nobody can just
kill it. I know it's not a real protection, but intent
was to place a security system in such place where it
will be more protected by itself. I placed additional
security mechanisms in the place where designers of
UNIX placed theirs (file permissions an so on) - in
the kernel.
> Doing interpretation of LISP is a monster compared
> to some piddly
> context switches.
When people say LISP they mean Common LISP, which is a
monster and I agree with you. VXE uses stripped down
version of LISP and syntax of LISP is far simpler than
C for example.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Tuesday 06 April 2004 00:52, you wrote:
> --- Robin Rosenberg <[email protected]>
>
> wrote:
> > On Monday 05 April 2004 23:30, Sergiy Lozovsky
> >
> > wrote:
> > > Point me to ANy langage with VM around 100K.
> >
> > There is a Java VM (lejos) f?r the Lego Mindstorms
> > robot. The hardware
> > has 32K memory.
>
> Is it Free and Open Source? Where can I get it if it
> is?
http://www.lejos.org. Mozilla License 1.0 (Not sure about GPL compatibility if you
were to have wierd plans).
But, it has no GC- I doubt adding GC would add many K's. On the other hand you
might want to be careful with GC inside the kernel :-)
-- robin
On Tuesday 06 April 2004 00:52, Sergiy Lozovsky wrote:
> (I don't want to start Holly War :-) but I think, that
> Java is lower lavel than C, I recognize, that I can be
> wrong)
Yes, you could..., but that's OT. Isn't LISP lower level. Just
the names of it's instructions (Content of Address part of Register and
Content of Decrement part of Register) imply that. Shudddrdrrddrr. :-)
I like Lisp, it's a hacker language, or was at least.
-- robin
--- Robin Rosenberg <[email protected]>
wrote:
> On Tuesday 06 April 2004 00:52, Sergiy Lozovsky
> wrote:
> > (I don't want to start Holly War :-) but I think,
> that
> > Java is lower lavel than C, I recognize, that I
> can be
> > wrong)
> Yes, you could..., but that's OT. Isn't LISP lower
> level. Just
> the names of it's instructions (Content of Address
> part of Register and
> Content of Decrement part of Register) imply that.
> Shudddrdrrddrr. :-)
>
> I like Lisp, it's a hacker language, or was at
> least.
>
> -- robin
Sounds like music to me :-) If I would not be (very)
familiar with LISP prior to that project, I would not
chose it probably. It's syntax is so simple (it is a
marvel :-) I would think twice to put in the kernel
something with more complex syntax.
After all Emacs uses LISP, too :-) Though it is this
big one - Common Lisp :-)
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Mon, 5 Apr 2004 20:02:00 -0700 (PDT) Sergiy Lozovsky <[email protected]> wrote:
|
| --- Robin Rosenberg <[email protected]>
| wrote:
| > On Tuesday 06 April 2004 00:52, Sergiy Lozovsky
| > wrote:
| > > (I don't want to start Holly War :-) but I think,
| > that
| > > Java is lower lavel than C, I recognize, that I
| > can be
| > > wrong)
| > Yes, you could..., but that's OT. Isn't LISP lower
| > level. Just
| > the names of it's instructions (Content of Address
| > part of Register and
| > Content of Decrement part of Register) imply that.
| > Shudddrdrrddrr. :-)
| >
| > I like Lisp, it's a hacker language, or was at
| > least.
| >
| > -- robin
|
|
| Sounds like music to me :-) If I would not be (very)
| familiar with LISP prior to that project, I would not
| chose it probably. It's syntax is so simple (it is a
| marvel :-) I would think twice to put in the kernel
| something with more complex syntax.
|
| After all Emacs uses LISP, too :-) Though it is this
| big one - Common Lisp :-)
I always knew that emacs was just another OS. 8;}
--
~Randy
On Monday 05 April 2004 18:49, Sergiy Lozovsky wrote:
> --- Timothy Miller <[email protected]> wrote:
> > Sergiy Lozovsky wrote:
> > > LSM use another way of doing similar things :-)
> >
> > I'm
> >
> > > not sure that it is nice to forward system calls
> >
> > back
> >
> > > to userspace where they came from in the first
> >
> > place
> >
> > > :-) VXE use high level language to create security
> > >
> > > models.
> >
> > "Kernel space -> user space -> kernel space" is
>
> To be more precise "user space -> kernel space -> user
> space -> kernel space -> user space"
>
> against ordinary "user space -> kernel space -> user
> space"
>
> So, what happens - task makes system calls and blocks;
> request goes to a user space security server. Will it
> process request right away? No, it will wait for
> scheduler to chose it for execution. Ok server got CPU
> and returns results to the kernel. Will initial task
> continue? No, it will wait for be chosen by scheduler.
> This is what I call overhead (though i understand,
> that can be wrong). My system (VXE) doesn't involve
> scheduler at all.
Depends on what the requirement is. In some cases you
MUST do this - otherwise the tables required for making
the decision would be WAY too large for the kernel.
Some models even require reference to remote hosts
for validation. The current Kerberos authentication
requires this. So do AFS requests.
Other requests can be satisfied by a cached table entry
without waiting.
> So we should not just look into length of this chain
> at the picture. - "user space -> kernel space -> user
> space -> kernel space -> user space" - we should
> remember that it involves to mandatory task switches
> to accomplish jus one system call.
It only depends on the request. If the entire security
context is local, then this is not required.
> > nothing compared to the
> > overhead of a LISP interpreter.
>
> LISP code, is very small actually. And nobody can just
> kill it. I know it's not a real protection, but intent
> was to place a security system in such place where it
> will be more protected by itself. I placed additional
> security mechanisms in the place where designers of
> UNIX placed theirs (file permissions an so on) - in
> the kernel.
LISP code (if compiled machine code) IS small. LISP
VM is not - when you combine it with the lisp code,
the heap management, and garbage collector. And you
can STILL have memory leaks out the wazoo. To prevent
the memory leaks you have to have a mark and sweep GC.
Which still doesn't prevent circular loop leaks. Then
you need a memory pool allocator to relocate all valid
references. The combination is NOT small. BTW, the JVM
suffers from circular loop leaks too, since all it uses
is reference counting (for speed).
> > Doing interpretation of LISP is a monster compared
> > to some piddly
> > context switches.
>
> When people say LISP they mean Common LISP, which is a
> monster and I agree with you. VXE uses stripped down
> version of LISP and syntax of LISP is far simpler than
> C for example.
No - they mean the VM + garbage collector + error handler +
the lisp pcode.
On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy Lozovsky wrote:
> > Consider rewriting your function to use allocated
> > memory instead of stack, this isn't all that hard.
>
> I put LISP interpreter inside the Kernel -
> http://vxe.quercitron.com
>
> It works, but it use a lot of stack memory. It's
> impossible to rewrite it easily, though I'll
> investigate why exactly it uses so much of stack
> memory (though it's nature of LISP). There are no
> serious kernel memory allocation (as of my interpreter
> code review, only function calls; recursions in LISP
> application itself are eliminated for sure), but I'll
> trace stack usage more thouroughly.
>
Consider this. We're currently experimenting with a
transition from 8k to 4k stacks on x86, and that is
considered a very good thing. Allocating a single-
page stack is easy, two (contigous) pages might fail.
So a bigger kernel stack is out.
As for rewriting code so it doesn't use stack - it
_is_ easy, but it might be a lot of _work_.
The simple approach is to replace all (big) stack
allocations with an explicit stack structure that you manages
on the heap. There'll be more code, but it won't be slower
because all the extra code is stuff that happen automatically
with the hw stack. (I.e. stuff the compiler normally take
care of.)
There is some more work if your interpreter also does deep recursion.
It involves making one big function of those that do the recursion
and manage the "calls" yourself with an array and a switch statement.
Again, not particularly hard, but it could take some time to implement.
Helge Hafting
Jesse Pollard <[email protected]> writes:
> To prevent the memory leaks you have to have a mark and sweep GC.
> Which still doesn't prevent circular loop leaks.
What are you talking about? A mark/sweep GC certainly DOES collect
circular data structures.
Perhaps you are thinking of reference counting GCs?
> Then you need a memory pool allocator to relocate all valid
> references.
Now you seem to talking about stop and copy, which is something else
again. And it is not required to avoid memory leaks, although it does
fix fragmentation.
> The combination is NOT small. BTW, the JVM suffers from circular
> loop leaks too, since all it uses is reference counting (for speed).
Which JVM are you talking about? Every JVM I know of uses a real
garbage collector, not some reference counting hack.
Perhaps you are thinking of Perl?
Sergiy is right: A Lisp interpreter and runtime can be quite small and
efficient. And it can provide a secure "sandbox" for running
questionable code safely.
Whether it is a good idea in this context is another question. My
concern is that it is hard (impossible?) to bound the memory
consumption, both stack AND heap, of a Lisp program statically. I
would expect such bounds to be important for an implementation of a
security model. With a Lisp program, you cannot be sure under what
conditions it will exceed whatever space you have alloted for it.
Which means that, although it cannot crash the kernel, it cannot be
used to build a reliable system, either...
- Pat
If stack will shrink - i'll come up with something.
Rearchitecture of LISP interpreter - is too much work.
(and I'm lazy - I prefer computer to do a work, not me
:-)
I checked what is going on with the stack - it is used
to pass parameters, some functions have one or two
local variables (4 bytes each) and that's it.
I like to develop tools and general solutions :-) To
solve the stack problem in a way which will not cause
big changes in any existing code - I can make stack
virtualization. API can be different, but idea is the
same. Task has some memory allocated by malloc
(vstack) which is used for saving data from real
stack. One of the APIs - scall function:
scall(pointer_to_vstack, number_of_arguments,
pointer_to_function_to_call, arg1, arg2,...)
scall checks if real stack is full enough - it stores
it's content in the vstack and moves %esp to the
bottom of the real stack. When user function returns -
information from vstack moves to the real one (one
movl instruction at Intel x86).
In case of LISP there is only one place where it will
be enough to use scall - eval function.
In other subsystems - it can be needed to call in a
few places. But in such way a new 4K stack could be
used without serious rewriting of existing code.
vstack can grow dynamically if needed (within defined
limit).
Serge.
--- Helge Hafting <[email protected]> wrote:
> On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy
> Lozovsky wrote:
> > > Consider rewriting your function to use
> allocated
> > > memory instead of stack, this isn't all that
> hard.
> >
> > I put LISP interpreter inside the Kernel -
> > http://vxe.quercitron.com
> >
> > It works, but it use a lot of stack memory. It's
> > impossible to rewrite it easily, though I'll
> > investigate why exactly it uses so much of stack
> > memory (though it's nature of LISP). There are no
> > serious kernel memory allocation (as of my
> interpreter
> > code review, only function calls; recursions in
> LISP
> > application itself are eliminated for sure), but
> I'll
> > trace stack usage more thouroughly.
> >
> Consider this. We're currently experimenting with a
> transition from 8k to 4k stacks on x86, and that is
> considered a very good thing. Allocating a single-
> page stack is easy, two (contigous) pages might
> fail.
>
> So a bigger kernel stack is out.
>
> As for rewriting code so it doesn't use stack - it
> _is_ easy, but it might be a lot of _work_.
>
> The simple approach is to replace all (big) stack
> allocations with an explicit stack structure that
> you manages
> on the heap. There'll be more code, but it won't be
> slower
> because all the extra code is stuff that happen
> automatically
> with the hw stack. (I.e. stuff the compiler normally
> take
> care of.)
>
> There is some more work if your interpreter also
> does deep recursion.
> It involves making one big function of those that do
> the recursion
> and manage the "calls" yourself with an array and a
> switch statement.
> Again, not particularly hard, but it could take some
> time to implement.
>
> Helge Hafting
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Horst von Brand <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
> > --- John Stoffel <[email protected]> wrote:
> > > >>>>> "Sergiy" == Sergiy Lozovsky
> > > <[email protected]> writes:
>
> [...]
>
> > UNIX security policy is already implemented in the
> > Kernel,
>
> Basic mechanism, not policy.
In case of VXE even mechanism is not stored inside the
kernel! This was the main goal - not to store(encode)
security model (mechanism) in the kernel. In VXE it is
loadable as well as particular security policy. It
loads on demand (during the start of subsystem) and
unloads when subsystem ends it work.
When susbsytem doesn't run - model and policy are
stored as a file.
VXE allow to preload model and policy if that is
desired, but it's just one of the options.
>
> Policy has no place inside the kernel.
Root privileges (ability to send a signal to any
process, access any file and so on) are encoded in the
kernel.
> [...]
>
> > > Then *WHY* does the LISP interpreter need to be
> in
> > > the kernel in the
> > > first place? Hint, you just said you wanted to
> > > protect the kernel...
> >
> > All LISP errors are incapsulated within LISP VM.
>
> They aren't. A bad kprintf(), or a call to the wrong
> function inside the
> kernel, or fiddling with the wrong data structure,
> and you are toast.
No. LISP program can't call kprintf. Only VM can. LISP
program prints information into string buffer of
limited size and VM uses snprintf for that. When
buffer is full or there is \n - VM calls kprintf.
So all interaction with the kernel goes via VM.
Investing some time into carefull parameter check in
VM allows to avoid the same work for each new
application.
VM is not 100% foolproof - I don't claim that, but it
reduces problems which a new application (within the
kernel) can cause.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Horst von Brand <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
>
> [...]
>
> [...]
>
> > No matter what particular LISP program does - it
> can't
> > crash the kernel - C code can do that easily.
>
> If the policy check goes into an infinite loop, the
> kernel proper isn't
> technically crashed, but useless anyway. And if you
> can prove that can't
> happen, you just solved the halting problem.
> Congratulation!
My code works during system calls (before the real
one). Interrupts are enabled. If it enters the loop
scheduler still can switch tasks (using timer for
example). If it doesn't work in such way I can easily
call schedule(); implicitly after some time limit will
be reached - it's VM, so it's easy to do such things.
So, it's my pleasure to accept your congratulations
:-) Thanks.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
>>>>> "Sergiy" == Sergiy Lozovsky <[email protected]> writes:
>> Policy has no place inside the kernel.
Sergiy> Root privileges (ability to send a signal to any process,
Sergiy> access any file and so on) are encoded in the kernel.
But that does not require a LISP interpreter in the kernel either.
And you are also mistaking policy with a capability. Who has root is
a policy, what root can do is a capability. They are seperate issues.
Sergiy> So all interaction with the kernel goes via VM. Investing
Sergiy> some time into carefull parameter check in VM allows to avoid
Sergiy> the same work for each new application.
You have not given us a simple example of how this VM would be used in
the kernel and what it provides. I think that would help people
understand why you think this is so needed.
So just start with a process, explain how it wants to do some
restricted action, and how your VM would be required to mediate that
access. Some simple flow charting and explaining of what steps would
happen and why would be a big help.
Personally, I think you're completely confusing policy with
capabilities. Since the setting of policy is completely a user-space
issue, while the checking of capabilities is handled in the kernel.
And if the capability check requires a VM to do some mediation, that
capability check gets pushed out to userspace, instead of kept in the
VM in the kernel like you seem to want.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
Helge Hafting wrote:
> The simple approach is to replace all (big) stack
> allocations with an explicit stack structure that you manages
> on the heap.
Maybe Stackless Python is a better fit for this kernel project?
:) [1/2 serious]
-- Jamie
--- John Stoffel <[email protected]> wrote:
> >>>>> "Sergiy" == Sergiy Lozovsky
> <[email protected]> writes:
>
> >> Policy has no place inside the kernel.
>
> Sergiy> Root privileges (ability to send a signal to
> any process,
> Sergiy> access any file and so on) are encoded in
> the kernel.
>
> But that does not require a LISP interpreter in the
> kernel either.
> And you are also mistaking policy with a capability.
> Who has root is
> a policy, what root can do is a capability. They
> are seperate issues.
UID is stored in a task structure in the kernel as
well as what to do with it. With VXE both policy and
capability are in a file (out of the kernel), though
there is an option to preload it into the kernel
before execution of particular system starts.
> Sergiy> So all interaction with the kernel goes via
> VM. Investing
> Sergiy> some time into carefull parameter check in
> VM allows to avoid
> Sergiy> the same work for each new application.
>
> You have not given us a simple example of how this
> VM would be used in
> the kernel and what it provides. I think that would
> help people
> understand why you think this is so needed.
I though I did. Here is a link to the site with
detailed description of the system. It works since
1999. - http://vxe.quercitron.com
It's not an example - it's working system.
There was an article in LinuxFocus - it's less
technical and more compact -
http://jamesthornton.com/linux/LinuxFocus/English/January2000/article133.shtml
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
You want these guys to fry me? :-) Do you like it well
done? :-)
Serge.
--- Jamie Lokier <[email protected]> wrote:
> Helge Hafting wrote:
> > The simple approach is to replace all (big) stack
> > allocations with an explicit stack structure that
> you manages
> > on the heap.
>
> Maybe Stackless Python is a better fit for this
> kernel project?
>
> :) [1/2 serious]
>
> -- Jamie
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Patrick J. LoPresti wrote:
> Whether it is a good idea in this context is another question. My
> concern is that it is hard (impossible?) to bound the memory
> consumption, both stack AND heap, of a Lisp program statically. I
> would expect such bounds to be important for an implementation of a
> security model. With a Lisp program, you cannot be sure under what
> conditions it will exceed whatever space you have alloted for it.
> Which means that, although it cannot crash the kernel, it cannot be
> used to build a reliable system, either...
>
I think 100K is rather large for an interpretor to be included in the
kernel, but putting that aside...
It's a limited number of people who would actually write these policies.
If those people follow certain coding rules, then we CAN have such
bounds, by convention. Yes, those bounds could be violated, but if the
programmer (not sysadmin -- they would never write these things in LISP)
breaks something, it's just a bug.
Mostly it would be kernel programmers who write the policies, and those
would appear in some /etc directory, put there by Red Hat, and
selectable by admins using some GUI.
Someone writing a policy which caused the VM to explode would be no
different from nVidia writing a kernel driver which did it more directly.
The advantage of scripting the policy (which is essentially what this
is) is that they could be switchable more dynamically, and they could
refer to kernel structures more abstractly.
On Tue, 6 Apr 2004, Sergiy Lozovsky wrote:
>
> --- Horst von Brand <[email protected]> wrote:
> > Sergiy Lozovsky <[email protected]> said:
> > > --- John Stoffel <[email protected]> wrote:
> > > > >>>>> "Sergiy" == Sergiy Lozovsky
> > > > <[email protected]> writes:
> >
> > [...]
> >
> > > UNIX security policy is already implemented in the
> > > Kernel,
> >
> > Basic mechanism, not policy.
>
> In case of VXE even mechanism is not stored inside the
> kernel! This was the main goal - not to store(encode)
> security model (mechanism) in the kernel. In VXE it is
> loadable as well as particular security policy. It
> loads on demand (during the start of subsystem) and
> unloads when subsystem ends it work.
>
> When susbsytem doesn't run - model and policy are
> stored as a file.
>
> VXE allow to preload model and policy if that is
> desired, but it's just one of the options.
>
> >
> > Policy has no place inside the kernel.
>
> Root privileges (ability to send a signal to any
> process, access any file and so on) are encoded in the
> kernel.
>
That's not policy. That's mechanism (one of many).
> > > > Then *WHY* does the LISP interpreter need to be
> > in
> > > > the kernel in the
> > > > first place? Hint, you just said you wanted to
> > > > protect the kernel...
> > >
> > > All LISP errors are incapsulated within LISP VM.
> >
> > They aren't. A bad kprintf(), or a call to the wrong
> > function inside the
> > kernel, or fiddling with the wrong data structure,
> > and you are toast.
>
Let me get this right. You learned LISP right?
Now you think it's the only way to go. There is
a name for this, where one starts to identify
with his captors... It's called the Stockholm
Syndrome, named after four Swedes bound in bank-
vault for six days became attached to their captors.
LISP is just a TOOL and a poor one, at that. There
are many tools available under Unix/Linux and, if
you don't like what's available, you can readily
make your own. Once you learn new tools, the Stockholm
Syndrome will go away although you'll probably always
like the first tool you learned to use. I like DDT,
myself.
Nobody who has a clue would suggest LISP inside a kernel.
When I first read this, I was sure it was an April-fool
joke, although somewhat cruel, kinda like; "what to do
with a dead cat..."
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Tue, 06 Apr 2004 11:16:03 PDT, Sergiy Lozovsky said:
> My code works during system calls (before the real
> one). Interrupts are enabled. If it enters the loop
> scheduler still can switch tasks (using timer for
> example). If it doesn't work in such way I can easily
> call schedule(); implicitly after some time limit will
> be reached - it's VM, so it's easy to do such things.
Yes, but your security manager is *still* in an infinite loop, and eventually
you *will* come to a grinding halt, as each process gets queued up waiting for
a decision from the security manager.
As an aside, the original posting said it was a restricted subset of Lisp that
didn't include recursion. Aside from the technical difficulties of detecting
two or more routines that mutually recurse, it's unclear that Lisp without
recursion is at all interesting or useful....
This is sounding more and more like the old adage: "When all you have
is a hammer, everything starts looking like a thumb".
Sergiy Lozovsky <[email protected]> said:
> --- Horst von Brand <[email protected]> wrote:
> > Sergiy Lozovsky <[email protected]> said:
> >
> > [LISP inside the kernel?!]
> >
> > > Basically there are two reasons.
> > >
> > > 1. Give system administrator possibility to change
> > > security policy easy enough
> >
> > SELinux
>
> To create a new 'security model' one should write a C
> program within Selinux user space security server.
> People like to use higher level languages.
C is a high level language. If you don't like it, use C++, Perl, Ruby, TCL,
Guile, Common LISP, PostScript, ... It's userspace, program in whatever you
like most.
> > > without C programminig
> > > inside the kernel (we should not expect system
> > > administartor to be a kernel guru).
> > As 97.572% of the job has to be done in userland anyway, place your
> > checks/high-level language/GUI frobnitzer in there at will. Compile to a
> > compact, easy-to-handle, digitally signed, binary blob and stuff _that_
> > into the kernel as needed.
> I'm not ready to put a binary compiled with Common
> Lisp or PERL (if it exists)
Yep.
> compilers into the kernel.
Again.... use something written in C, Perl, Common LISP, even COBOL to
parse the description and generate a binary blob from it that you then
stuff into the kernel. No in-kernel runtime for high-level general purpose
languages needed at all.
> At the same time I want people to benefit from using
> high level langages (even kernel gurus don't use
> Assembler all the time, higher level languages is
> easier to use and less lines of code to write).
Kernel gurus write C and think assembler. Wrong crowd selected ;-)
> .....
>
> > > 2. Protect system from bugs in security policy
> > > created by system administrator (user).
> > Sounds like you are demanding a solution to Turing's test here... and
> > also to the halting problem.
> I didn't claim that I solve all problems on earth :-)
You certainly do. How do you protect the system from a mistaken policy that
takes away all rights from the user supposed to manage it, and gives them
to the local script kiddie instead?
> What I can claim:
> 1. Some kernel parts can be developed with language of
> higher level than C.
It efficiency doesn't matter, do it in userland. If efficiency matters, do
it in hand-tuned C + assembly, inside the kernel only if there is no other
way.
> 2. Problems with such parts can be to some extent be
> encapsulated within VM (no, it's not 100% fool prof
> for sure), but it helps.
Doing it in userland helps even more.
> 3. Code can be easily debugged in the user space
> (running with user space VM) and used in the kernel
> after that.
The environment isn't the same, so this doesn't help that much. Besides, if
the job _can_ be done in userland, it has no business being done in the
kernel. Stuff is being moved _out_ of the kernel (for example, finding
partitions and filesystems) as we speak...
[...]
> LISP code is located in the kernel. Application issues a system call LISP
> program checks arguments of this call. If LISP program fails (crashes) -
> VM will return default value which is EACCESS, so application will get
> 'access denied'. (and will fail, probably).
So the idea is _userland_ code stuffed into the _kernel_ to be checked and
executed there? And if it is broken, and denies all access, it is a nice
DoS.
--
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
Sergiy Lozovsky <[email protected]> said:
> --- Timothy Miller <[email protected]> wrote:
> >
> >
> > Sergiy Lozovsky wrote:
> >
> > >
> > >
> > > All LISP errors are incapsulated within LISP VM.
> > >
> >
> >
> > A LISP VM is a big, giant, bloated.... *CHOKE*
> > *COUGH* *SPUTTER*
> > *SUFFOCATE* ... thing which SHOULD NEVER be in the
> > kernel.
>
> It is a smallest interpreter (of all purpose language)
> I was able to find. My guess is that you refer to the
> Common Lisp. it is huge and I don't use it.
Nope. Timothy was talking exactly of the same one as you. And I agree with
him.
> > If you want to use a more abstract language for
> > describing kernel
> > security policies, fine. Just don't use LISP.
>
> Point me to ANy langage with VM around 100K.
Assembler. VM is exactly _zero_ overhead. Or C, for a tiny bit more. That
one was already paid for, so you essentially get it for free. Might also
hack FORTH, for a few KiB (dunno how much this days, but should be less
than 10 for a stripped to the bone package).
> > The right way to do it is this:
> >
> > - A user space interpreter reads text-based config
> > files and converts
> > them into a compact, easy-to-interpret code used by
> > the kernel.
> >
> > - A VERY TINY kernel component is fed the security
> > policy and executes it.
Nodz!
> it is exactly the way it is implemented.
And how does an _in kernel_ LISP interpreter fit into this picture? Lost me
there...
> Not everyone
> need to create their own security model (that VERY
> TINY kernel component you refer to).
Now we have common ground...
> But even for
> those who want to modify or create their own VERY TINY
> kernel component - they don't need to do that in C and
> debug it in th kernel crashing it.
... of sorts.
Right, I don't want the security kernel inside the kernel crashing. But
then again, I don't want the driver for the hard disk, or the mouse, or
even the graphic card, scribbling over memory either. Guess you'd (re)write
the whole kernel in some LISP dialect then? Good luck! But this is
_certainly_ the worst list to discuss such a design.
[...]
> > Why do you choose LISP? Don't you want to use a
> > language that sysadmins
> > will actually KNOW?
>
> It was is) the smallest VM I know of.
You know little...
> 99% of sysadmins don't need to create their own
> security models. Security polices are created with web
> interface very close to the way you described. So
> sysadmin don't need to know anything about LISP (to
> use predefined security models).
OK, so you need the policy to be interpreted in-kernel (dunno why a
largeish high-level general purpose language is needed for that, when a
tiny interpreter for a specialized language will do very well, and has been
shown to work fine), and written in a "high level language" so that your
garden variety sysadmin _can_ write her own policy, but it really doesn't
matter because she'll never have to do so...
Completely lost me.
--
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:
> OK, so you need the policy to be interpreted in-kernel (dunno why a
> largeish high-level general purpose language is needed for that, when a
> tiny interpreter for a specialized language will do very well, and has been
> shown to work fine), and written in a "high level language" so that your
> garden variety sysadmin _can_ write her own policy, but it really doesn't
> matter because she'll never have to do so...
>
> Completely lost me.
I was getting hung up on that one too, but I didn't know how to say it.
You did a nice job. :)
Timothy Miller <[email protected]> writes:
> I think 100K is rather large for an interpretor to be included in the
> kernel, but putting that aside...
I think we are all putting that aside for the moment. :-)
> It's a limited number of people who would actually write these
> policies. If those people follow certain coding rules, then we CAN
> have such bounds, by convention. Yes, those bounds could be violated,
> but if the programmer (not sysadmin -- they would never write these
> things in LISP) breaks something, it's just a bug.
Fair enough. But then I wonder how many of Lisp's advantages you
would lose. I am having trouble imagining "statically bounded Lisp"
without being so stylized as to hardly be Lisp at all.
- Pat
Patrick J. LoPresti wrote:
>>It's a limited number of people who would actually write these
>>policies. If those people follow certain coding rules, then we CAN
>>have such bounds, by convention. Yes, those bounds could be violated,
>>but if the programmer (not sysadmin -- they would never write these
>>things in LISP) breaks something, it's just a bug.
>
>
> Fair enough. But then I wonder how many of Lisp's advantages you
> would lose. I am having trouble imagining "statically bounded Lisp"
> without being so stylized as to hardly be Lisp at all.
>
Given that the original author admits that the sysadmins using this
would never actually write any LISP code, I too fail to see why LISP
would be of any help here.
If you want to be compact and efficient, some really simple
pseudo-language would do the job well enough. Optimize for speed of
execution and compactness of both interpreter and policy code, not for
easy of writing in the language.
I mean, by choosing LISP, "ease of writing in the language" was thrown
out the window to begin with! :)
I think this points us in the direction of something like Forth. Take
OpenBoot for example. I wrote Forth-like interpreters in Pascal when I
was in highschool.
But if you DO want sysadmins to be able to write this, then something
resembling shell script would be better. It wouldn't be quite like
shell scripting, but it would LOOK like it, and it would have to be
compiled (by the program that you run to load the policy) into something
compact and easy to interpret before being fed to the kernel.
Another possibility is to develop a set of tools that compile policies
written in C into modules that are loaded/unloaded into the kernel
dynamically. :) The compile process would be transparent to the user,
because the "insert this policy" tool would run it through GCC (unless
the cached .ko was already up to date, etc.).
--- "Richard B. Johnson" <[email protected]>
wrote:
> On Tue, 6 Apr 2004, Sergiy Lozovsky wrote:
>
> Let me get this right. You learned LISP right?
25 years ago.
> Now you think it's the only way to go. There is
> a name for this, where one starts to identify
> with his captors... It's called the Stockholm
> Syndrome, named after four Swedes bound in bank-
> vault for six days became attached to their captors.
Last time I used LISP (except of the project we
discuss) was 18 years ago (on IBM mainframes). So your
conclusion doesn't sound right :-)
I never used any LISP on PC prior to VXE project.
> LISP is just a TOOL and a poor one, at that. There
> are many tools available under Unix/Linux and, if
> you don't like what's available, you can readily
> make your own. Once you learn new tools, the
> Stockholm
> Syndrome will go away although you'll probably
> always
> like the first tool you learned to use. I like DDT,
> myself.
>
> Nobody who has a clue would suggest LISP inside a
> kernel.
> When I first read this, I was sure it was an
> April-fool
> joke, although somewhat cruel, kinda like; "what to
> do
> with a dead cat..."
So, you still didn't say a word why it was a bad
choice. Can you share your thought on that?
I didn't just pick up LISP - I EXPLAINED my reasons.
if you missed my explanation here is a short summary.
1. I needed solution to implement some procedural
functionality within the kernel. This functionality
should be expressed with some high level language
(shorter development time and more compact source
code). This functionality should be
loadable/unloadable to the kernel.
2. Size of the interpreter should be minimal.
3. Kind of real time - no ordinary garbage collector.
And automatic memory management at the same time.
4. Easiest syntax possible - so interpreter would be
compact. Simpler - the better :-) I don't like
complicated things :-)
5. Well known. So there would be people around who
already know this language and expectations are clear.
And there are books around about this language.
6. Ability to handle/represent complex data
structures.
7. Errors/bugs in loadable functions should not cause
trouble for other tasks and kernel itself. (To the
extent possible for sure).
8. It should be universal (general purpose) language
which gives ability to make any manipulations with
numbers, strings, bits and data structures. So I would
be sure that functionality I want to express is not
limited by the language.
That's why particular LISP interpreter was chosen.
It's wrong to say that just language was chosen. I
would never start work of fitting Common Lisp into the
kernel. Particular general purpose language
interpreter was chosen.
Serge.
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine
> (797.90 BogoMips).
> Note 96.31% of all statistics are
> fiction.
>
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- [email protected] wrote:
> On Tue, 06 Apr 2004 11:16:03 PDT, Sergiy Lozovsky
> said:
>
> > My code works during system calls (before the real
> > one). Interrupts are enabled. If it enters the
> loop
> > scheduler still can switch tasks (using timer for
> > example). If it doesn't work in such way I can
> easily
> > call schedule(); implicitly after some time limit
> will
> > be reached - it's VM, so it's easy to do such
> things.
>
> Yes, but your security manager is *still* in an
> infinite loop, and eventually
> you *will* come to a grinding halt, as each process
> gets queued up waiting for
> a decision from the security manager.
No. VXE has completely different architecture.
Separate logical copy of LISP program is for each
subsystem we protect. (sure they share the same code
of LISP interpreter). So, if there will be any
problems - it's for particular subsystem only. Other
subsystems (protected and not protected) will not be
affected.
It's like event driven model. There is no constantly
running servers.
> As an aside, the original posting said it was a
> restricted subset of Lisp that
> didn't include recursion. Aside from the technical
> difficulties of detecting
> two or more routines that mutually recurse, it's
> unclear that Lisp without
> recursion is at all interesting or useful....
It's misunderstanding. There are no any recursion
restrictions. Author of particular security model
(LISP program) should avoid recursions; it's not very
hard actually. When we write program at language other
than LISP - we rarely use recursion. Yes, it's against
LISP style, but not a big problem.
> This is sounding more and more like the old adage:
> "When all you have
> is a hammer, everything starts looking like a
> thumb".
I know the better one.
"As all Real Programmers know, the only useful data
structure is the Array. Strings, Lists, Structures,
Sets-- these are all special cases of arrays and can
be treated that way just as easily without messing up
your programming language with all sorts of
complications."
http://www.pbm.com/~lindahl/real.programmers.html
Serge :-)
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Timothy Miller <[email protected]> wrote:
>
>
> Horst von Brand wrote:
>
> > OK, so you need the policy to be interpreted
> in-kernel (dunno why a
> > largeish high-level general purpose language is
> needed for that, when a
> > tiny interpreter for a specialized language will
> do very well, and has been
> > shown to work fine), and written in a "high level
> language" so that your
> > garden variety sysadmin _can_ write her own
> policy, but it really doesn't
> > matter because she'll never have to do so...
> >
> > Completely lost me.
>
> I was getting hung up on that one too, but I didn't
> know how to say it.
> You did a nice job. :)
Can you guys be more specific? I don't see any
technical objections. The only one is that performance
would suffer because of use of higher level language
than C or Assembler.
There is a reason people use languages like PERL, Java
and so on. I would prefer to spend less time writing
actual code - this is what these high level languages
for. If performance would be most important - people
would do everything in Assembler, but they don't. I'd
better write a small Assembler subroutine which will
handle stack problems for me and benefit from using
the high level language after that.
There were times when userland projects were written
in Assembler. Now people are using other languages,
too. May be it's time to try something new in the
kernel, too :-) Or we will not consider that because
nobody did that before? Someone should be the first
:-)
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky wrote:
>
> So, you still didn't say a word why it was a bad
> choice. Can you share your thought on that?
I've seen (and produced) lots of words to that effect.
>
> I didn't just pick up LISP - I EXPLAINED my reasons.
> if you missed my explanation here is a short summary.
>
> 1. I needed solution to implement some procedural
> functionality within the kernel. This functionality
> should be expressed with some high level language
> (shorter development time and more compact source
> code). This functionality should be
> loadable/unloadable to the kernel.
This isn't a problem.
>
> 2. Size of the interpreter should be minimal.
You say your LISP interpreter is about 100K. This is hardly minimal.
There are things which are much smaller which will do the job AND won't
have the stack-exploding side-effects.
>
> 3. Kind of real time - no ordinary garbage collector.
> And automatic memory management at the same time.
How about one which doesn't NEED garbage collection? For instance, if
you were to make it object-based, rather than object-oriented, then
you'd pre-allocate all structures at compile time. Ada is(was?) like this.
>
> 4. Easiest syntax possible - so interpreter would be
> compact. Simpler - the better :-) I don't like
> complicated things :-)
LISP completely violates this requirement. There are languages which
have MUCH simpler syntax than LISP.
And I'm talking simpler for the PROGRAMMER. It can be as complex as you
like for the compiler, because THE COMPILER WOULD BE IN USERSPACE.
>
> 5. Well known. So there would be people around who
> already know this language and expectations are clear.
> And there are books around about this language.
LISP completely violates this requirement. While I appreciate the power
of LISP for abstraction, list processing, and how it lends itself
towards many AI-related tasks, it's not a commonly-used language.
Besides, you have already invalidated this point by stating that the
people actually USING this policy engine would never look at the code,
because they would select amongst a set of canned policies using a web
browser. In this case, the form of the policy code is completely
irrelevant.
> 6. Ability to handle/represent complex data
> structures.
LISP is not superior to other languages in this regard. I
handle/represent complex data structures in C, C++, Java, Javascript,
PHP, SQL, BASIC, Pascal, Tcl... I guess FORTRAN is the only one I don't
do complex structures in.
> 7. Errors/bugs in loadable functions should not cause
> trouble for other tasks and kernel itself. (To the
> extent possible for sure).
The only way to be sure of this is to do the processing in userspace.
Putting that aside, any carefully-written interpreter would be able to
provide this security. Furthermore, something simpler than a LISP
interpreter would be easier to VERIFY that it was secure.
>
> 8. It should be universal (general purpose) language
> which gives ability to make any manipulations with
> numbers, strings, bits and data structures. So I would
> be sure that functionality I want to express is not
> limited by the language.
Again, LISP is not superior to other languages in this regard.
> That's why particular LISP interpreter was chosen.
> It's wrong to say that just language was chosen. I
> would never start work of fitting Common Lisp into the
> kernel. Particular general purpose language
> interpreter was chosen.
You have to understand that you're speaking to a list full of zealots
that understand zealotry VERY WELL. Even Linux scratches his head (or
so I assume) every time some Linux zealot comes along wanting to run
Linux on some two-bit (pun intended) processor that was never designed
to run an OS.
Thus, when someone comes along suggesting that they put a beast like a
LISP interpreter into the Kernel, something that violates Linux
philosophy on SOOO many levels, the "he must be a LISP zealot" red
lights start flashing, because only a LISP/whatever zealot would choose
to do something so ostensibly impractical. That is to say, someone who
was NOT a LISP/whatever zealot would have chosen something more
appropriate, while we have observed so many times
Linux/LISP/MacOS/BeOS/Perl/Ruby/Python/whatever zealots who want to push
their square peg into every round hole they can find. (so to speak)
I personally like to write Nuclear Bomb simulators in BASH to run on
5mhz processors with 1K of RAM. *snort*
Sergiy Lozovsky wrote:
> It's misunderstanding. There are no any recursion
> restrictions. Author of particular security model
> (LISP program) should avoid recursions; it's not very
> hard actually. When we write program at language other
> than LISP - we rarely use recursion. Yes, it's against
> LISP style, but not a big problem.
If you are going to throw away the most basic and fundamental feature of
LISP for this..... why use LISP?
Sergiy Lozovsky wrote:
> --- Timothy Miller <[email protected]> wrote:
>
>>
>>Horst von Brand wrote:
>>>OK, so you need the policy to be interpreted
>>in-kernel (dunno why a
>>>largeish high-level general purpose language is
>>needed for that, when a
>>>tiny interpreter for a specialized language will
>>do very well, and has been
>>>shown to work fine), and written in a "high level
>>language" so that your
>>>garden variety sysadmin _can_ write her own
>>policy, but it really doesn't
>>>matter because she'll never have to do so...
>>>Completely lost me.
>>
>>I was getting hung up on that one too, but I didn't
>>know how to say it.
>> You did a nice job. :)
>
>
> Can you guys be more specific? I don't see any
> technical objections. The only one is that performance
> would suffer because of use of higher level language
> than C or Assembler.
That IS one of the objections, but it's not the objection HERE.
The objection here is that we see an inconsistency:
A) You support the idea of using LISP because it's a high-level language
that sysadmins can use to develop policies.
B) But then you say that sysadmins won't be developing policies.
Therefore, you invalidate your reason for wanting to use LISP.
>
> There is a reason people use languages like PERL, Java
> and so on. I would prefer to spend less time writing
> actual code - this is what these high level languages
> for. If performance would be most important - people
> would do everything in Assembler, but they don't. I'd
> better write a small Assembler subroutine which will
> handle stack problems for me and benefit from using
> the high level language after that.
As a matter of fact, the only reason people object to using LISP is
because you want to do it IN THE KERNEL.
If you want the interpreter to live in the kernel, then you have to use
something MUCH SIMPLER and something which doesn't eat stack like LISP does.
On the other hand, if you were to put hooks into the kernel so that
people could use ANY LANGUAGE THEY WANTED, IN USER SPACE, then people
would be very happy with you. This way, you can waste all the memory
you want on the interpreter, but it's okay because it's:
(1) extremely optional
(2) extremely replacable (interpretor can be any language)
(3) swappable
(4) can't clobber the kernel
(5) can use as much stack space as it wants
(6) minimally impacts what IS in the kernel, etc.
You down-play the performance impact of using LISP above, but you
contradict that by saying you want to put the interpreter in the kernel
for performance reasons. You can't have it both ways. Either you're
concerned about performance (and you use something efficient and
compact), or you're not concenred about performance (and you use
whatever high-level language you want IN USERSPACE).
>
> There were times when userland projects were written
> in Assembler. Now people are using other languages,
> too. May be it's time to try something new in the
> kernel, too :-) Or we will not consider that because
> nobody did that before? Someone should be the first
> :-)
The kernel is not the appropriate place for this. An OS kernel exists
to provide a minimal set of services necessary for applications to make
efficient use of resources. (Microkernels take this to the extreme with
their layering.) Only when something CANNOT be accomplished in
userspace (or performance in userspace is terrible) should something be
put into the kernel.
As I've said before, the overhead of actually interpreting a high-level
language is probably great enough that the context-switch overhead you
don't want would diminish.
On Tue, Apr 06, 2004 at 06:44:48PM -0400, Timothy Miller wrote:
> >5. Well known. So there would be people around who
> >already know this language and expectations are clear.
> >And there are books around about this language.
>
> LISP completely violates this requirement. While I appreciate the power
> of LISP for abstraction, list processing, and how it lends itself
> towards many AI-related tasks, it's not a commonly-used language.
Whether it's commonly-used or not, there's another killer problem with LISP -
it's fragmented worse than even Pascal. And "which subset and extensions
do we have in $IMPLEMENTATION" is worth "which language are we dealing with".
Worse, actually. If you want a functional language - at least pick a
well-defined one.
--- Timothy Miller <[email protected]> wrote:
>
>
> Sergiy Lozovsky wrote:
> > --- Timothy Miller <[email protected]> wrote:
> >
> >>
> >>Horst von Brand wrote:
>
> >>>OK, so you need the policy to be interpreted
> >>in-kernel (dunno why a
> >>>largeish high-level general purpose language is
> >>needed for that, when a
> >>>tiny interpreter for a specialized language will
> >>do very well, and has been
> >>>shown to work fine), and written in a "high level
> >>language" so that your
> >>>garden variety sysadmin _can_ write her own
> >>policy, but it really doesn't
> >>>matter because she'll never have to do so...
> >>>Completely lost me.
> >>
> >>I was getting hung up on that one too, but I
> didn't
> >>know how to say it.
> >> You did a nice job. :)
> >
> >
> > Can you guys be more specific? I don't see any
> > technical objections. The only one is that
> performance
> > would suffer because of use of higher level
> language
> > than C or Assembler.
>
> That IS one of the objections, but it's not the
> objection HERE.
>
> The objection here is that we see an inconsistency:
>
> A) You support the idea of using LISP because it's a
> high-level language
> that sysadmins can use to develop policies.
>
> B) But then you say that sysadmins won't be
> developing policies.
>
> Therefore, you invalidate your reason for wanting to
> use LISP
If I would say, that policy administrator change
security policy (not system administrator :-). Would
it be an answer to your question? I don't want this
person to be a kernel guru and make him write a C code
for Kernel. I don't want errors of this person to
affect all the system - which is a case with
precompiled loadable C module.
> >
> > There is a reason people use languages like PERL,
> Java
> > and so on. I would prefer to spend less time
> writing
> > actual code - this is what these high level
> languages
> > for. If performance would be most important -
> people
> > would do everything in Assembler, but they don't.
> I'd
> > better write a small Assembler subroutine which
> will
> > handle stack problems for me and benefit from
> using
> > the high level language after that.
>
> As a matter of fact, the only reason people object
> to using LISP is
> because you want to do it IN THE KERNEL.
>
> If you want the interpreter to live in the kernel,
> then you have to use
> something MUCH SIMPLER and something which doesn't
> eat stack like LISP does.
What? Give an example. I want something high level, so
Forth will not do. Sure, encapsulation is needed, to
protect kernel from pointer errors and so on.
> On the other hand, if you were to put hooks into the
> kernel so that
> people could use ANY LANGUAGE THEY WANTED, IN USER
> SPACE, then people
> would be very happy with you. This way, you can
> waste all the memory
> you want on the interpreter, but it's okay because
> it's:
>
> (1) extremely optional
> (2) extremely replacable (interpretor can be any
> language)
> (3) swappable
> (4) can't clobber the kernel
> (5) can use as much stack space as it wants
> (6) minimally impacts what IS in the kernel, etc.
>
> You down-play the performance impact of using LISP
> above, but you
> contradict that by saying you want to put the
> interpreter in the kernel
> for performance reasons. You can't have it both
> ways. Either you're
> concerned about performance (and you use something
> efficient and
> compact), or you're not concenred about performance
> (and you use
> whatever high-level language you want IN USERSPACE).
I'm looking for balance. I want to benefit from high
level language and have reasonable performance.
>
>
> >
> > There were times when userland projects were
> written
> > in Assembler. Now people are using other
> languages,
> > too. May be it's time to try something new in the
> > kernel, too :-) Or we will not consider that
> because
> > nobody did that before? Someone should be the
> first
> > :-)
>
> The kernel is not the appropriate place for this.
> An OS kernel exists
> to provide a minimal set of services necessary for
> applications to make
> efficient use of resources. (Microkernels take this
> to the extreme with
> their layering.)
This is a good explanation, why I use kernel. You
admitted that microkernels are extreme. I didn't want
to change such basic architectural model of Linux.
What you suggest to do is to make microkernel. Sys
call goes to kernel, instead of serving this request
you suggest to forward this call to the userspace,
than get it back and continue to serv it in the
kernel. Worse of two worlds - kernels serv syscalls
inside, microkernels - outside; you suggest to serv it
both - outside and inside.
It was hard for me to predict performance and
architectural penalties of such solution. For each
syscall perform - task switch (can we predict when
scheduler decided to give control to the userspace
security server and than back to initial
appliaction?), context switch (kernelspace/userspace
and back), priority switch - process which issued sys
call is with one priority, security server - with
another. System behaviour become very complex and
forwarding syscalls to userspace affects basic
architecture of Linux.
> Only when something CANNOT be
> accomplished in
> userspace (or performance in userspace is terrible)
> should something be
> put into the kernel.
>
> As I've said before, the overhead of actually
> interpreting a high-level
> language is probably great enough that the
> context-switch overhead you
> don't want would diminish.
This overhead is very predictable (having the size of
particular security policy and defined security
model). So it close to real-time, which is good for
kernel. Switching between tasks, environments and
priorites during the service of just one system call
is not predicatble at all and more complex.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- [email protected] wrote:
> On Tue, Apr 06, 2004 at 06:44:48PM -0400, Timothy
> Miller wrote:
> > >5. Well known. So there would be people around
> who
> > >already know this language and expectations are
> clear.
> > >And there are books around about this language.
> >
> > LISP completely violates this requirement. While
> I appreciate the power
> > of LISP for abstraction, list processing, and how
> it lends itself
> > towards many AI-related tasks, it's not a
> commonly-used language.
>
> Whether it's commonly-used or not, there's another
> killer problem with LISP -
> it's fragmented worse than even Pascal.
Can I have more details? All LISPs I know manage
memory by themselves as well as the one I use. They
allocate memory pool, create a list of free cells in
it and that's it. What is the problem? Yes, cells in
the free list are not contiguous, it's a list.
> And "which
> subset and extensions
> do we have in $IMPLEMENTATION" is worth "which
> language are we dealing with".
> Worse, actually. If you want a functional language
> - at least pick a
> well-defined one.
I use a subset of big lisps (Common Lisp should I
say?). All function are described in manual which goes
with my system. And I'm not going to run some
previously created LISP programs. So exact
compatibility is not an issue. At the same time if a
person wants to understand what is CAR or CDR - there
are different sources of information available except
manual I provide (which is reference, not a LISP
textbook).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Wednesday 07 April 2004 01:32, Sergiy Lozovsky wrote:
> --- [email protected] wrote:
> > Whether it's commonly-used or not, there's another
> > killer problem with LISP -
> > it's fragmented worse than even Pascal.
>
> Can I have more details? All LISPs I know manage
> memory by themselves as well as the one I use. They
> allocate memory pool, create a list of free cells in
> it and that's it. What is the problem? Yes, cells in
> the free list are not contiguous, it's a list.
Not memory fragmentation, language definition fragmentation.
There is no language called "LISP" (except the original). There are several
dozen strains with slighly or very different syntax, scope rules and other
variations. LISP1.5, MacLisp, Emacs Lisp, AutoLisp, Common Lisp, Scheme to
mention a very few of the more known species, and most of these come in
different dialects.
-- robin
--- "J.A. Magallon" <[email protected]> wrote:
>
> On 7 abr 2004, at 01:17, Sergiy Lozovsky wrote:
> >
> > What? Give an example. I want something high
> level, so
> > Forth will not do. Sure, encapsulation is needed,
> to
> > protect kernel from pointer errors and so on.
> >
>
> Ple
What is this? I used PL/1 some time ago, is PLE - PL/1
Extended? Or Enlarged? (just kidding)
If you will provide link to the source code with
documentation - that would help.
Google knows nothing about Ple. (just to check it out
I tried to search for LISP - google knows it well :-).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky <[email protected]> said:
> If stack will shrink - i'll come up with something.
Good luck! When it is done shrinking, there won't be much (if any) left for
you to play with.
> Rearchitecture of LISP interpreter - is too much work.
Implement a kernel-side LISP interpreter isn't...
> (and I'm lazy - I prefer computer to do a work, not me
> :-)
Nodz. But even better is _not_ doing it at all ;-)
> I checked what is going on with the stack - it is used
> to pass parameters, some functions have one or two
> local variables (4 bytes each) and that's it.
Why do you think it has been 2 pages (8KiB) for as long as I remember
(essentially forever in Linux), and it has taken a _lot_ of work to shrink
it to 4KiB (- size of *current)?
--
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 <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
>
> Why do you think it has been 2 pages (8KiB) for as
> long as I remember
> (essentially forever in Linux), and it has taken a
> _lot_ of work to shrink
> it to 4KiB (- size of *current)?
I described the possible solution (virtual stack)
which can easily take care of this problem for some
subsystems, or am I wrong. If code doesn't allocate
big buffers in stack my solution can make conversion
of existing code possible without _lot_ of work. (I'm
lazy - remember :-)
What do you think about my solution? Despite some
additional overhead, but I don't think that it is
significant.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky <[email protected]> said:
[...]
> I didn't just pick up LISP - I EXPLAINED my reasons.
> if you missed my explanation here is a short summary.
>
> 1. I needed solution to implement some procedural
> functionality within the kernel.
Fair enough, if really needed.
> This functionality
> should be expressed with some high level language
> (shorter development time and more compact source
> code).
That it is _expressed_ in a sky-high-level-language has nothing at all to
do with _implementing_ said language (fully?) inside the kernel. Heck, the
kernel has no built-in C compiler + development environment + runtime
either!
> This functionality should be
> loadable/unloadable to the kernel.
A compact, easy to interpret blob pushed into the kernel, a module hooking
into the "right places", ...
> 2. Size of the interpreter should be minimal.
Zero is just about right for me.
> 3. Kind of real time - no ordinary garbage collector.
> And automatic memory management at the same time.
Oxymoron.
> 4. Easiest syntax possible - so interpreter would be
> compact. Simpler - the better :-) I don't like
> complicated things :-)
Why do you need the interpreter in kernel? If you do need it, why does it
have to be a general-purpose language, and not an "interpreter" for a
stylized data structure, carefully designed for the task?
> 5. Well known. So there would be people around who
> already know this language and expectations are clear.
> And there are books around about this language.
C is fine in that sense. Even much better than LISP. Specially among the
sysadmin/kernel hacker/general Unix geek crowd...
> 6. Ability to handle/represent complex data
> structures.
C qualifies.
> 7. Errors/bugs in loadable functions should not cause
> trouble for other tasks and kernel itself. (To the
> extent possible for sure).
Hard to do in any case. Just be careful...
> 8. It should be universal (general purpose) language
> which gives ability to make any manipulations with
> numbers, strings, bits and data structures. So I would
> be sure that functionality I want to express is not
> limited by the language.
But _why_?
--
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
On Tue, Apr 06, 2004 at 09:02:49PM -0400, Horst von Brand wrote:
> Sergiy Lozovsky <[email protected]> said:
> > If stack will shrink - i'll come up with something.
>
> Good luck! When it is done shrinking, there won't be much (if any) left for
> you to play with.
>
> > Rearchitecture of LISP interpreter - is too much work.
>
> Implement a kernel-side LISP interpreter isn't...
It's a userland (and leaky, at that) LISP interpreter plus some glue and duct
tape to make it kinda-sorta work in kernel mode - enough for a demo, in any
case. BTW, the LISP dialect implemented by that interpreter is unimpressive,
to put it mildly. Even aside of atrocious "GC" and lexer (BTW, have the
author of RefLISP ever heard of arcane technics known as "checking the return
value of malloc"?), semantics of his EVAL would be a shame even in 70s (at
any point after Landin's papers, actually). Sigh...
Sergiy Lozovsky <[email protected]> said:
> --- Timothy Miller <[email protected]> wrote:
> > Horst von Brand wrote:
> > > OK, so you need the policy to be interpreted in-kernel (dunno why
> > > a largeish high-level general purpose language is needed for that,
> > > when a tiny interpreter for a specialized language will do very well,
> > > and has been shown to work fine), and written in a "high level
> > > language" so that your garden variety sysadmin _can_ write her own
> > > policy, but it really doesn't matter because she'll never have to do
> > > so...
> > > Completely lost me.
> > I was getting hung up on that one too, but I didn't
> > know how to say it.
> > You did a nice job. :)
> Can you guys be more specific? I don't see any
> technical objections.
As they say around here "No hay peor ciego que el que no quiere ver"
(roughly, "There is no worse blindness than not wanting to see")...
> The only one is that performance
> would suffer because of use of higher level language
> than C or Assembler.
Because the performance and size of kernel code is _critical_, maybe?
Because much of the kernel code has been carefully tuned for maximum
performance perhaps?
> There is a reason people use languages like PERL, Java
> and so on.
And there are solid reasons for _not_ writing operating system kernels in
them too...
> I would prefer to spend less time writing
> actual code - this is what these high level languages
> for. If performance would be most important - people
> would do everything in Assembler, but they don't. I'd
> better write a small Assembler subroutine which will
> handle stack problems for me and benefit from using
> the high level language after that.
And then there is the technology of _inventing_ a language tailored to the
task at hand... even better than your list of high-level languages.
> There were times when userland projects were written
> in Assembler. Now people are using other languages,
> too.
In part because a mediocre compiler these days gives better code than an
assembly language coder by hand... and you can compile it for next year's
machine too.
> May be it's time to try something new in the
> kernel, too :-) Or we will not consider that because
> nobody did that before? Someone should be the first
> :-)
It's your time you are wasting... have my blessing.
--
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" == Horst von Brand <[email protected]> writes:
>> The only one is that performance would suffer because of use of
>> higher level language than C or Assembler.
Horst> Because the performance and size of kernel code is _critical_,
Horst> maybe? Because much of the kernel code has been carefully
Horst> tuned for maximum performance perhaps?
>> There is a reason people use languages like PERL, Java and so on.
Horst> And there are solid reasons for _not_ writing operating system
Horst> kernels in them too...
Hey, why not just port Xemacs to run on the bare metal. That way you
get a lisp interpreter `for free'. :-)
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*
On Tue, Apr 06, 2004 at 06:34:50PM -0700, Sergiy Lozovsky wrote:
>
> --- Horst von Brand <[email protected]> wrote:
> > Sergiy Lozovsky <[email protected]> said:
> >
> > Why do you think it has been 2 pages (8KiB) for as
> > long as I remember
> > (essentially forever in Linux), and it has taken a
> > _lot_ of work to shrink
> > it to 4KiB (- size of *current)?
>
> I described the possible solution (virtual stack)
> which can easily take care of this problem for some
> subsystems, or am I wrong. If code doesn't allocate
> big buffers in stack my solution can make conversion
> of existing code possible without _lot_ of work. (I'm
> lazy - remember :-)
You know, to me the combination of lazy programmer rhymes poorly with
well-written code and security audits.
> What do you think about my solution? Despite some
> additional overhead, but I don't think that it is
> significant.
Personally, I think this proposal would be worthy for the
patch-of-the-month award.
Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
David Weinehall wrote:
> Personally, I think this proposal would be worthy for the
> patch-of-the-month award.
I dunno...the proposal to rewrite the kernel and libc in assembly is
pretty high up there....
Chris
On Tuesday 06 April 2004 11:40, Patrick J. LoPresti wrote:
> Jesse Pollard <[email protected]> writes:
> > To prevent the memory leaks you have to have a mark and sweep GC.
> > Which still doesn't prevent circular loop leaks.
>
> What are you talking about? A mark/sweep GC certainly DOES collect
> circular data structures.
>
> Perhaps you are thinking of reference counting GCs?
Ummm. I wasn't precise, sorry. some of the structures I was
thinking of must be imported from outside the LISP vm. Think
inode data, skb structures, parts of the security context. These
are not allocated by the LISP vm, and are not supported by it.
And these may be lost by it. I say may, since some security
aspects of these structures must be allocated by it (the VM),
and then passed externally to provid tracking capabilities.
Deallocation via mark/sweep would cause dangling pointers in these
external structures. And if you don't pass allocated structures to
these kernel objects then you must search for the corresponding
structures to the objects when a security decision must be made
(more overhead - which was why the LSM added security blob pointers
to the various structures).
The pure LISP structures are recovered - I was actually thinking
about the overhead of the mark/sweep causing significant amounts
of fragmentation until the mark/sweep is completed, which can still
leave a LOT of fragmentation behind.
> > Then you need a memory pool allocator to relocate all valid
> > references.
>
> Now you seem to talking about stop and copy, which is something else
> again. And it is not required to avoid memory leaks, although it does
> fix fragmentation.
Yup. And it is hard. But even mark/sweep algorithms require that the
LISP interpreter stop. This was one of the problems with early LISP
machines - they would stop for 3-10 seconds during the mark/sweep - their
solution: two processors, and memory pools.
> > The combination is NOT small. BTW, the JVM suffers from circular
> > loop leaks too, since all it uses is reference counting (for speed).
>
> Which JVM are you talking about? Every JVM I know of uses a real
> garbage collector, not some reference counting hack.
Most JVM used (at least the ones I've run across) are not designed for server
use. These are very small JVMs, and they use reference counting. Once
the applet terminates, so does the JVM, and when restarted, it resets
memory allocations (aka memory pool).
> Perhaps you are thinking of Perl?
Nope. I have seen some small LISP interpreters use reference counting
- even wrote one of my own.
> Sergiy is right: A Lisp interpreter and runtime can be quite small and
> efficient. And it can provide a secure "sandbox" for running
> questionable code safely.
Provided you don't depend on a GC, and have a way to prevent failure
(aborts) from causing system wide failure - which is a problem with
security reference monitors.
> Whether it is a good idea in this context is another question. My
> concern is that it is hard (impossible?) to bound the memory
> consumption, both stack AND heap, of a Lisp program statically. I
> would expect such bounds to be important for an implementation of a
> security model. With a Lisp program, you cannot be sure under what
> conditions it will exceed whatever space you have alloted for it.
> Which means that, although it cannot crash the kernel, it cannot be
> used to build a reliable system, either...
It is impossible to guarantee memory bounds without eliminating most
of the capability of LISP (specific applications + data can be proven
bounded, but the general case cannot). The inherent recursive structure
forces the memory to be unbound (especially the stack) in presence of
multiple function interactions. Sometimes (many times?) the recursive
structure can be eliminated by a very good optimizer, but this takes
both time and overhead - and is aimed at generating "just in time"
machine code, not LISP pcode.
--- Chris Friesen <[email protected]> wrote:
> David Weinehall wrote:
>
> > Personally, I think this proposal would be worthy
> for the
> > patch-of-the-month award.
>
> I dunno...the proposal to rewrite the kernel and
> libc in assembly is
> pretty high up there....
My proposal gives ability to avoid rewriting of code
and saves time. If there is a time to rewrite code -
it can be rewritten. For parts we don't have time to
rewrite - virtual stack can be used without serious
code modifications.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- David Weinehall <[email protected]> wrote:
> On Tue, Apr 06, 2004 at 06:34:50PM -0700, Sergiy
> Lozovsky wrote:
> >
> > --- Horst von Brand <[email protected]> wrote:
> > > Sergiy Lozovsky <[email protected]> said:
> > >
> > > Why do you think it has been 2 pages (8KiB) for
> as
> > > long as I remember
> > > (essentially forever in Linux), and it has taken
> a
> > > _lot_ of work to shrink
> > > it to 4KiB (- size of *current)?
> >
> > I described the possible solution (virtual stack)
> > which can easily take care of this problem for
> some
> > subsystems, or am I wrong. If code doesn't
> allocate
> > big buffers in stack my solution can make
> conversion
> > of existing code possible without _lot_ of work.
> (I'm
> > lazy - remember :-)
>
> You know, to me the combination of lazy programmer
> rhymes poorly with
> well-written code and security audits.
Don't take my non technical comments too seriously.
Life is too short to be serious all the time. If I was
not successful in making a joke - sorry.
(there was an old joke that programmers are very lazy
people - they don't like to work, so they write
programs and computers work for them; I just quoted
this joke).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Horst von Brand <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
> > --- Timothy Miller <[email protected]> wrote:
> > > Horst von Brand wrote:
> > I would prefer to spend less time
> writing
> > actual code - this is what these high level
> languages
> > for. If performance would be most important -
> people
> > would do everything in Assembler, but they don't.
> I'd
> > better write a small Assembler subroutine which
> will
> > handle stack problems for me and benefit from
> using
> > the high level language after that.
>
> And then there is the technology of _inventing_ a
> language tailored to the
> task at hand... even better than your list of
> high-level languages.
I started exactly with that. I found out shortly that
have no idea of functionality needed for such kind of
system. It was clear that requirments for this sytem
can change rapidly. Only general purpose language can
address this problem (if we want to save time of
development and introduction of new security models).
Example. Current security policies are 'static'. It
seems, that it would be nice to have 'dynamic'
policies (with support from security model). Now,
policy describes resources available for subsystem. It
may be useful to limit the sequence of access to
resources - 'behaviour' of subsystem. I'm not sure if
I want to implement that right away, but there is
commercial system which does exactly that already (it
was created later than VXE).
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky <[email protected]> said:
> --- Horst von Brand <[email protected]> wrote:
[...]
> > And then there is the technology of _inventing_ a
> > language tailored to the
> > task at hand... even better than your list of
> > high-level languages.
> I started exactly with that. I found out shortly that
> have no idea of functionality needed for such kind of
> system.
Come back when you have found out.
> It was clear that requirments for this sytem
> can change rapidly.
I would not trust anything with "rapidly changing requirements" as security
infrastructure.
> Only general purpose language can
> address this problem (if we want to save time of
> development and introduction of new security models).
A security model has to be exhaustively scrutinized, proved correct and
complete, and well-tested. The implementation language is completely
irrelevant, the hard work is _not_ programming.
> Example. Current security policies are 'static'.
In what sense?
> It
> seems, that it would be nice to have 'dynamic'
> policies (with support from security model).
Again, what does this mean?
> Now,
> policy describes resources available for subsystem.
No...
> It
> may be useful to limit the sequence of access to
> resources - 'behaviour' of subsystem. I'm not sure if
> I want to implement that right away, but there is
> commercial system which does exactly that already (it
> was created later than VXE).
What is the use of restricting access sequences? If sequence A, B, C is
forbidden, chances are that C, B, A (or any of the other 4 permutations)
will give an attacker exactly what he wants.
--
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 <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
> > --- Horst von Brand <[email protected]> wrote:
>
> [...]
>
> > > And then there is the technology of _inventing_
> a
> > > language tailored to the
> > > task at hand... even better than your list of
> > > high-level languages.
>
> > I started exactly with that. I found out shortly
> that
> > have no idea of functionality needed for such kind
> of
> > system.
>
> Come back when you have found out.
Sorry. I live in the real world. In 1999 I had servers
to protect. One of them was hacked and I started to
look for tools which could protect servers. I found
NOTHING. (there were some Intrusion Detection Systems,
which would alert you when your server was ALREADY
hacked - it was completely unacceptable for me).
So I created VXE. Problem was solved. I could not sit
and think about some perfect design while my servers
were in the net unprotected, it's too expensive.
Speed is not most important for me. If I have fast but
unprotected server - it is of no use for me.
>
> > It was clear that requirments for this
> sytem
> > can change rapidly.
>
> I would not trust anything with "rapidly changing
> requirements" as security
> infrastructure.
VXE worked for me. It was much better than nothing.
> > Only general purpose language
> can
> > address this problem (if we want to save time of
> > development and introduction of new security
> models).
>
> A security model has to be exhaustively scrutinized,
> proved correct and
> complete, and well-tested. The implementation
> language is completely
> irrelevant, the hard work is _not_ programming.
>
> > Example. Current security policies are 'static'.
>
> In what sense?
Actually one 'dynamic' feature is implemented in VXE.
In ordinary system resource has permissions which
allows access or not. For higher security VXE can
count number of allowed accesses. For example, we are
securing POP server. We allow it to open /etc/passwd,
/etc/shadow for reading only once (counter is 1). So,
if hacker breaks to POP server after it opened
/etc/passwd - there is no way hacker can open this
file.
Another 'dynamic' feature is changing policy on the
fly. For now POP server can access all mailboxes in
/var/spool/mail - it's easy to add ability to modify
policy. After POP server authorized user it changes
it's UID - at that point we can set access to
/var/spool/mail/user_1 only. So POPD couldn't access
other files in all mailbox directories.
> >
> It
> > seems, that it would be nice to have 'dynamic'
> > policies (with support from security model).
>
> Again, what does this mean?
>
> > Now,
> > policy describes resources available for
> subsystem.
>
> No...
>
> >
> It
> > may be useful to limit the sequence of access to
> > resources - 'behaviour' of subsystem. I'm not sure
> if
> > I want to implement that right away, but there is
> > commercial system which does exactly that already
> (it
> > was created later than VXE).
>
> What is the use of restricting access sequences? If
> sequence A, B, C is
> forbidden, chances are that C, B, A (or any of the
> other 4 permutations)
> will give an attacker exactly what he wants.
VXE can have counters assigned to syscall parameters.
More sophisticated way is to have determined sequence
of syscalls. So, if hackers broke in the system
(sendmail for example) he can just follow logic of the
system - do the work of sendmail for you :-)
I can't say how easy to use this, but the company (my
competitors :-) which created this is entercept.com -
it seems, that they were very successful - I went to
their site right now and was redirected to Network
Associates - they were bought out, my guess.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Sergiy Lozovsky <[email protected]> said:
> --- Horst von Brand <[email protected]> wrote:
> > Sergiy Lozovsky <[email protected]> said:
[...]
> > > I started exactly with that. I found out shortly that
> > > have no idea of functionality needed for such kind of
> > > system.
> > Come back when you have found out.
> Sorry. I live in the real world. In 1999 I had servers
> to protect. One of them was hacked and I started to
> look for tools which could protect servers. I found
> NOTHING. (there were some Intrusion Detection Systems,
> which would alert you when your server was ALREADY
> hacked - it was completely unacceptable for me).
We had an unwellcome visitor in 2001... scrapped SomeOtherUnix shortly
thereafter (a "security fix" installed a "remote administration facility"
(complete with an extremely nice, well-known hole), which the cracker then
used to "remotely administer" our machine...), no further trouble since it
is all Linux now. Just be careful in what you install, how you configure,
and keep patches up to date.
I.e., a bit of common sense and care goes a _long_ way. Security is mostly
a _people_ affair, and has much to do with being careful and attention to
detail, it is not at all technical. Trying to solve such a people problem
with (misguided) technical measures gets you nowhere.
--
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
hi :)
On Tue, Apr 06, 2004 at 04:17:34PM -0700, Sergiy Lozovsky wrote:
> What? Give an example. I want something high level, so
> Forth will not do. Sure, encapsulation is needed, to
> protect kernel from pointer errors and so on.
who says that the language that's used by your policy administrator
is the same as the language interpreted by the kernel?
let your administrator write his policy in java/lisp or whatever,
but compile this policy into an easy to interpret and safe
bytecode.
--
CU, / Friedrich-Alexander University Erlangen, Germany
Martin Waitz // Department of Computer Science 12 _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet //
tippfehler und ist auch ohne grossbuchstaben gueltig. /
On Wed, 07 Apr 2004 21:07:56 PDT, Sergiy Lozovsky said:
> Actually one 'dynamic' feature is implemented in VXE.
> In ordinary system resource has permissions which
> allows access or not. For higher security VXE can
> count number of allowed accesses. For example, we are
> securing POP server. We allow it to open /etc/passwd,
> /etc/shadow for reading only once (counter is 1). So,
> if hacker breaks to POP server after it opened
> /etc/passwd - there is no way hacker can open this
> file.
Unless he finds an already open file descriptor for it and uses
read()/write()/mmap()/etc - did you audit your POP server
to make *really* sure that endpwent() is called at all the right
times, and that said function actually is guaranteed to close()
the file descriptor, and can't be forced into failing? (Note that
this can be caused by either close() syscall failing, or the attacker
managing to hijack the function entry point for either endpwent()
or close()....)
Unless he finds a copy of the file on the process heap (more than
one information leakage issue has come from THAT sort of problem)
Unless he opens a new file on the system, and writes a binary into
it, chmod's it to executable, and does a pipe/fork/exec and use
that program's quota of opens to read it...
And that's just the *obvious* end runs. As somebody else noted,
writing the code is the easy part....
--- [email protected] wrote:
> On Wed, 07 Apr 2004 21:07:56 PDT, Sergiy Lozovsky
> said:
>
> > Actually one 'dynamic' feature is implemented in
> VXE.
> > In ordinary system resource has permissions which
> > allows access or not. For higher security VXE can
> > count number of allowed accesses. For example, we
> are
> > securing POP server. We allow it to open
> /etc/passwd,
> > /etc/shadow for reading only once (counter is 1).
> So,
> > if hacker breaks to POP server after it opened
> > /etc/passwd - there is no way hacker can open this
> > file.
>
> Unless he finds an already open file descriptor for
> it and uses
> read()/write()/mmap()/etc - did you audit your POP
> server
> to make *really* sure that endpwent() is called at
> all the right
> times, and that said function actually is guaranteed
> to close()
> the file descriptor, and can't be forced into
> failing? (Note that
> this can be caused by either close() syscall
> failing, or the attacker
> managing to hijack the function entry point for
> either endpwent()
> or close()....)
Most common way of hacking a box looks much easier.
Usual way of stack problems was - to run shell using
security hole. Change root password or create new
account with root UID. All these usually done with
tools available at the system.
VXE use word Environment (description of available
resources), some systems use word Domain. There is no
shell, ls, vi and so on in POPD Environment. So, most
of attackers will just go away. One should be really
motivated to master unique binary code to hack VXE
protected system. Let's see what is possible even in
that case.
Let's assume there is a security hole in POPD. One
should create custom binary code to inspect RAM. How
to communicate information back to hacker? There
should be enough code to do that. This code should not
destroy POPD to such extent that it will end (or core
dumped), because hacker's code will end too. (POPD
doesn't need exec or fork for its work, so hacker
can't call these syscalls). So, in theory it is
possible to do some damage to particular subsystem,
but it's nearly impossible to compromise all system.
> Unless he finds a copy of the file on the process
> heap (more than
> one information leakage issue has come from THAT
> sort of problem)
If you have limited number syscalls (with limited
parameters you can call allowed syscalls) - it's VERY
hard to do. Purpose of VXE is to protect subsystems,
which can have security holes. In real life nobody can
gurantee, that there are no security holes in a given
system. Some time ago they constantly were finding
bugs in sendmail. Nevertheless people were using it.
> Unless he opens a new file on the system, and writes
> a binary into
> it, chmod's it to executable, and does a
> pipe/fork/exec and use
> that program's quota of opens to read it...
POPD doesn't use chmod/fork/exec, so that wouldn't
work - there are no these syscalls in POPD
Environment. Let's assume some file was created by
hacker in /var/spool/mailbox, so what? How that can
damage the system. (it's the only directory where POPD
can create/modify files).
> And that's just the *obvious* end runs. As somebody
> else noted,
> writing the code is the easy part....
So, in theory it is possible to make some damage to
hacked subsystem (POPD for example and damaged can be
only mailboxes), but the rest of the system will be
intact (and there is a lot of stuff in the system
except POPD). But in practice with such striped
environment - without shell, editors, limited set of
syscalls - generic hackers tools will not work. Only
if someone will dedicate efforts to create custom
tools for your particular site - he can damage
mailboxes at most (in case of POPD). I think, that it
is a pretty good result.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Hi, :-)
--- Martin Waitz <[email protected]> wrote:
> hi :)
>
> On Tue, Apr 06, 2004 at 04:17:34PM -0700, Sergiy
> Lozovsky wrote:
> > What? Give an example. I want something high
> level, so
> > Forth will not do. Sure, encapsulation is needed,
> to
> > protect kernel from pointer errors and so on.
>
> who says that the language that's used by your
> policy administrator
> is the same as the language interpreted by the
> kernel?
>
> let your administrator write his policy in java/lisp
> or whatever,
> but compile this policy into an easy to interpret
> and safe
> bytecode.
That will not give any benefits. LISP has internal
representation of program and data for sure
('bytecode'), but it is lists. How to unload it to
something one can move around? One of the ways -
unload it in a text form. But it exactly what initial
source code is. Parser of LISP is very small (because
syntax is simple), so producing some non standard
bytecode make no sense - source code of LISP is very
close to it's 'bytecode'.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
--- Horst von Brand <[email protected]> wrote:
> Sergiy Lozovsky <[email protected]> said:
> > --- Horst von Brand <[email protected]> wrote:
> > > Sergiy Lozovsky <[email protected]> said:
>
> [...]
>
> > > > I started exactly with that. I found out
> shortly that
> > > > have no idea of functionality needed for such
> kind of
> > > > system.
>
> > > Come back when you have found out.
>
> > Sorry. I live in the real world. In 1999 I had
> servers
> > to protect. One of them was hacked and I started
> to
> > look for tools which could protect servers. I
> found
> > NOTHING. (there were some Intrusion Detection
> Systems,
> > which would alert you when your server was ALREADY
> > hacked - it was completely unacceptable for me).
>
> We had an unwellcome visitor in 2001... scrapped
> SomeOtherUnix shortly
> thereafter (a "security fix" installed a "remote
> administration facility"
> (complete with an extremely nice, well-known hole),
> which the cracker then
> used to "remotely administer" our machine...), no
> further trouble since it
> is all Linux now. Just be careful in what you
> install, how you configure,
> and keep patches up to date.
>
> I.e., a bit of common sense and care goes a _long_
> way. Security is mostly
> a _people_ affair, and has much to do with being
> careful and attention to
> detail, it is not at all technical. Trying to solve
> such a people problem
> with (misguided) technical measures gets you
> nowhere.
I completely agree with you on that. Security is not
only technical issues. I was an owner of the company
when our server was hacked, so I did all explanations
for down time with our customers. (Downtime was
significant - server was collocated in another country
and it took quite a while for reinstall Linux -
different time zone, nobody on 24x7 duty...).
Advice to apply all new patches is good, one should do
that. But there are problems:
1. One should monitor patch development constantly and
be paid for that job (additional expenses).
2. Will be patch available in time and would it be
possible to find it - there are questions.
3. Some patches are created after security hole was
exploited. I don't want to be among these first sites
:-)
So, even if you patched everything - there are
security holes anyway (patches will be developed in
the future). If it is not production server - not a
big deal. If it is production - downtimes should be
minimal and stealing of sensitive information is
unacceptable. If kernel is slow - I'll buy faster
hardware with SMP if needed - it's not an issue at
all. Not enough - I'll install cluster, but I can't
allow system to be compromised.
Serge.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
On Thursday 08 April 2004 17:22, Sergiy Lozovsky wrote:
>
> Usual way of stack problems was - to run shell using
> security hole. Change root password or create new
> account with root UID. All these usually done with
> tools available at the system.
>
> VXE use word Environment (description of available
> resources), some systems use word Domain. There is no
> shell, ls, vi and so on in POPD Environment. So, most
> of attackers will just go away. One should be really
> motivated to master unique binary code to hack VXE
> protected system. Let's see what is possible even in
> that case.
>
> Let's assume there is a security hole in POPD. One
> should create custom binary code to inspect RAM. How
> to communicate information back to hacker? There
> should be enough code to do that. This code should not
> destroy POPD to such extent that it will end (or core
> dumped), because hacker's code will end too. (POPD
> doesn't need exec or fork for its work, so hacker
> can't call these syscalls). So, in theory it is
> possible to do some damage to particular subsystem,
> but it's nearly impossible to compromise all system.
Why shouldn't it?
It can just replace the entire code with itself.
and since you cannot prevent the use of mmap (which
is used to load the runtime libraries AND the executable)
it can still do that.
> > Unless he finds a copy of the file on the process
> > heap (more than
> > one information leakage issue has come from THAT
> > sort of problem)
>
> If you have limited number syscalls (with limited
> parameters you can call allowed syscalls) - it's VERY
> hard to do. Purpose of VXE is to protect subsystems,
> which can have security holes. In real life nobody can
> gurantee, that there are no security holes in a given
> system. Some time ago they constantly were finding
> bugs in sendmail. Nevertheless people were using it.
And they were fixing it. Not trying to make VERY kluged
work arounds in the kernel.
> > Unless he opens a new file on the system, and writes
> > a binary into
> > it, chmod's it to executable, and does a
> > pipe/fork/exec and use
> > that program's quota of opens to read it...
>
> POPD doesn't use chmod/fork/exec, so that wouldn't
> work - there are no these syscalls in POPD
> Environment. Let's assume some file was created by
> hacker in /var/spool/mailbox, so what? How that can
> damage the system. (it's the only directory where POPD
> can create/modify files).
You don't need to use chmod/fork/exec. It is entire possible
to replace the executable just by using mmap. I've already
written programs that deliberately do that (though I did use
dlopen). I've written a single binary that do anything. Including
running previously build applications.
After all - ld.so does just that during the initial load
an execed binary. All exec does is start ld.so with different
parameters... and nothing says that can't be done again.
And just not having a shell program on disk is silly - It
can be created rather easily. After all, that is what
root kits do routinely.
> > And that's just the *obvious* end runs. As somebody
> > else noted,
> > writing the code is the easy part....
>
> So, in theory it is possible to make some damage to
> hacked subsystem (POPD for example and damaged can be
> only mailboxes), but the rest of the system will be
> intact (and there is a lot of stuff in the system
> except POPD). But in practice with such striped
> environment - without shell, editors, limited set of
> syscalls - generic hackers tools will not work. Only
> if someone will dedicate efforts to create custom
> tools for your particular site - he can damage
> mailboxes at most (in case of POPD). I think, that it
> is a pretty good result.
It would be better to use a chroot environment.
Sergiy Lozovsky <[email protected]> said:
> Horst von Brand said:
[...]
> Working version of VXE was developed before SELinux.
Before Flux (the experimental OS that was used to demonstrate the ideas)?
Before the development of the architecture? SELinux is quite old, and the
ideas behind it even more...
In any case, who was first has very little to say about which one is
better.
> So you suggest using competing products, which were
> developed later :-) Are they better and easier to use?
> I'm not sure.
Doesn't matter if the product is completely off-track. I'd take anything
that was developed by some of the top people in the security area over
something by an amateur each day. Unless there is _solid_ evidence for the
amateurs, that is... and if they do completely nonsensical things like LISP
in kernel, that is in my view evidence that they don't even know what a
clue is.
[...]
> VXE is more granular and convenient tool, than chroot
> jail. Here is why:
>
> 1. It can be a complicated task, to move all needed
> file for chroot.
So?
> If it is a big system, like Oracle -
> it can be hard (it's possible, but too complicated).
In that case you can afford to set up a machine (or complete environment)
just for Oracle.
> VXE can protect working subsystems without making any
> changes in their location, nor configuration.
How? It requires _intimate_ knowledge of what the application needs, that
is very much unlikely to be in the hands of the hapless sysadmin in
charge. Who built the package in the first place is in a better position,
and for them it is easier to give directions on setting up a chroot jail
(available with any Unix!) than to fool around with a thinly-used,
experimental "security package" for an operating system that is on itself
(as yet) little used in hardened application needs.
> 2. Many systems have shared information. If we place
> subsystems in different chroot jails - who will
> synchronize this information? Example - sendmail and
> POPD - sendmail places mail into POPDs mailboxes. If
> they are in different chroot jails it is impossible.
No... they can comunicate over the network. Or share files by mounting an
area twice. By shared memory. By other shared resources inherited from a
common ancestor.
Besides, writing secured mail systems _has_ been done. Several times.
> Another example - many subsystems share /etc/passwd
> /etc/shadow information, if they are in different
> chroot jails - who will do synchronisation/data
> exchange between them?
NIS, NIS+, LDAP ring a bell?
> 3. If some file in chroot is read only - in case if
> hacker will get root - he can overwrite this file.
> It's not the case for VXE.
What part of "regular user in chroot jail" didn't you get? If you get root
in a chroot jail, the system is toast anyway.
[...]
> > Plus
> > you make the programmer's/configurator's job a _lot_
> > harder.
> You raised a very good question. It is exactly what
> makes VXE different from other systems. Many security
> systems don?t address this question, but VXE does.
You make the programmer's job essentially impossible. How on earth should I
know how many times my program will legitimately call open(2)? How do I
guarantee it does the same number of open(2)s each time? How do I ensure
all open(2)s are done before the cracker hijacks the program? What if glibc
changes, and now opens extra files behind my back? The only real anwers are
"specific r/w/x acces to <foo> required" and "<foo> is off-limits" (regular
permissions, perhaps ACLs) and "it does need to use it" or "it should never
use it" (something in the line of capabilities).
> That's why it's easy to use. One guy said that VXE is
> a self-learning system (I would not go so far, but
> would say that the process of building VXED (Virtual
> Executing Environment Description) or jail is
> automated. During creation of VXED - it runs in a test
> mode - collects information about resources used by
> the subsystem we want to put in 'jail'. In test mode
> all violations of VXED are registered in log, but
> syscalls are performed. So, administrator usually
> doesn?t add entries to VXED description - he just
> confirms inclusion of discovered resources to be
> included into VXED. Other thing administrator does is
> generalization - if POPD accessed
> /var/spool/mail/user1 - it's obviously should be
> changed to /var/spool/mail/*. In real VXED there are
> only a few entries which need generalization, so it's
> easy enough.
What a few particular test runs access is _not_ what all runs need, and
perhaps has little in common with what is required to do the job... that
requires knowledge of the task at hand, design and care. Just checking what
a particular (perhaps badly written) application does in a few test cases
is of absolutely no use for security.
> If it would not be automated - it would be a nightmare
> (as moving all needed files into chroot jail).
Same nightmare. Only probably much worse.
[...]
> 1. If you admit that chroot helps - VXE helps even
> more - it's superset of chroot features.
What is the cost of that "even more"? What new security risks are involved?
> 2. I didn't get it. POPD can not send e-mails.
It can communitate with whoever called it, if it is your cracker...
> It can
> alter mailboxes in a mailbox directory.
Adding, deleting, changing, rerouting delivered mail, ...
> So, what do
> you say? That some messages can be placed in mailboxes
> of existing users? (new users can't be created - no
> way to alter /etc/passwd).
That is quite enough for havoc.
[...]
> > There are much easier ways to do this. Besides, just
> > catching a problem
> > that might have security implications isn't really
> > enough (it means each
> > time the bug is triggered you get a crash). It would
> > be much better to work
> > on finding and fixing the bug.
> It's not the case in real life, that's why I gave a
> real example - sendmail. There were a lot of problems
> in sendmail for a long time - fixes were published
> continuously. And people were using it. We could give
> advice to sendmail developers to go and fix ALL bugs -
> I can imagine their answer to such suggestion :-)
They are finding and fixing bugs. There have been other architectures for
MTAs proposed, designed specifically for security (sendmail was born
_before_ security became an issue...). Same for other parts of the mail
system.
[...]
> There can be bugs in VXE as well as in chroot
> implementation, but people still use chroot. There are
> two ideas behind that:
There are a few other security mechanisms around...
> 1. VXE adds security mechanisms, without replacing
> existing mechanisms. So, is VXE fails there are two
> possibilities: - subsystem will be terminated (most
> likely - default value returned by small C code in
> case of troubles with the rest of VXE is EACCESS); -
> due to an error VXE will give permission for syscall -
> in such case subsystem will operate as it is without
> VXE, with existing security mechanisms; so - VXE
> increases protection of the system. (main goal is to
> prevent compromising of the system, though service can
> be disrupted in some cases).
Denial of service _is_ a security problem...
> 2. VXE mechanism is very simple enough - it's just
> additional code which checks parameters for sys calls.
In LISP code for each single call? You must be kidding...
[I must be pretty bored to still waste time on this nonsense...]
--
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