lkml.org 
[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support
Andrej Presern writes:
> It is intresting what you say here. I have tried to explain a concept
> much securer than what is being presented here to some people, but have
> failed in doing so because of being unable to provide the complete
> implementation details due to my lack of Linux internals knowledge.
>
> If you are interested, I would very much like to explain it again to
> you.

I, for one, would like to read it.

> > The whole UNIX philosophy is to give the user a powerful tool. Yes, giving
> > people such a tool does imply that people can hurt themselves. But I'd
> > still prefer to be given the choice, instead of getting the "yes, dear,
> > these are the safe and approved interfaces, and if you don't like them,
> > tough, you're stuck with them" mentality.
>
> Don't give authority to people, give it to objects in the system. A

This is mostly a symantic distinction. "People" do not exist within a
computer (The movie TRON not withstanding :). Only their data (files)
and agents (applications) = "objects" as you call them.

> separate authority from identity)

This is something that capabilities address very well.

> program should be able to do, so the program should only have as little
> authority as absolutely necessary to perform the action that a person
> designed it to do. Any more authority than that is a risk, because it

AKA, the "priniciple of minimal privilege" -- something that
capabilities take one very large step towards when compared with
setuid programs.

> I hope any of what I stated above will at least be considered before
> concepts that have _proven_ to be wrong are implemented in the kernel.
> In the last 30 years, a lot was learned about information security. I

I'm happy to say that capabilities as a concept have emerged from this
research. It is my understanding that they are preferable to many of
the other alternatives because they can be implemented in such a way
that does not slow down the kernel.

Best wishes

Andrew

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.365 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site