Re: Changing from L4 to something else...

[Bas Wijnen]

On Sun, Oct 30, 2005 at 07:53:36PM +0000, Neal H. Walfield wrote:
> At Sun, 30 Oct 2005 18:58:54 +0100,
> Bas Wijnen wrote:
> > On Sat, Oct 29, 2005 at 04:10:19AM +0200, Yoshinori K. Okuji wrote:
> > > On Friday 28 October 2005 07:10 pm, Jonathan Shapiro wrote:
> > > > It is a curious thing that people simultaneously want safety from the 
> > > > admin
> > > > and help from them. Sometimes you have to pick one or the other.
> > > 
> > > You are right. Fortunately or unfortunately, this is the truth. So I 
> > > repeatedly claim that balancing is the key point in making decisions.
> > 
> > Still, telling people "I am the owner of this computer, you can use it, and 
> > I
> > am not technically able to spy on you or change your things, except if you
> > give me your password" should be understandable for "normal" people.  When
> > they know this, they will also know that asking the the owner to change 
> > their
> > data without remembering their password will result in a negative response.
> > They may not like that, but I think they consider it a good idea to be
> > protected from the sysadmin.  And if they don't, nothing stops them from
> > installing a back door for him.  That is, this can be realised on a per-user
> > basis.  That sounds like a good idea to me. :-)
> 
> I don't buy this argument.  It seems pretty easy to me to implement
> su.  You just need the help of the session manager: if a task holds
> the super user capability, it can retrieve a capability to any user's
> session.
> 
> Or am I missing something?

I believe so.  When a session is started, it will generate a configuration
object.  With a capability to that object, the session can be configured.  I
assume you mean this capability with "a capability to a user's session".

This capability is _not_ given to the system administrator by default.  The
user can choose to give it, but if he does, it would be wise to use a
revocable version of it.  So unless the user permits the system administrator
to be super-user over him, the administrator cannot see what the user is
doing.  He can of course revoke capabilities to storage, to processor time, to
the terminal, and to anything else which may need to be forcefully claimed for
some other user.

Session details should be editable remotely when you autharize yourself (for
example with an ssh key).  Because of this, su from anything except root is
easily implemented (because authorization is performed).  But su from root
(without a password) is only possible if the user allowed it, and it isn't if
the user didn't allow it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature