l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing from L4 to something else...


From: Bas Wijnen
Subject: Re: Changing from L4 to something else...
Date: Sun, 30 Oct 2005 18:42:18 +0100
User-agent: Mutt/1.5.11

On Sat, Oct 29, 2005 at 04:01:03AM +0200, Yoshinori K. Okuji wrote:
> On Friday 28 October 2005 06:36 pm, Marcus Brinkmann wrote:
> > You put in another disk, and bill it to the customer.
> 
> I guess you are kidding. When things are really urgent, such a slow operation 
> is not allowed.

Note that the problem you described really means that there is too little disk
space in the computer.  This would be a problem in any other system as well
(with an administrator for example).

So no, I don't think Marcus was kidding.  But you should have put an extra
disk into the computer long before (and made sure that it wasn't used for less
important stuff.)  If you really want to allow this stuff, don't give your
whole disk away (so you still have some spare when you need it).

> > You subdivide the user's resources into "important data" and "scratch
> > space".  Thus, you give the user two resource capabilities (two
> > different "banks"). You promise your users that the "important data"
> > will not be revoked quickly.  You don't make the same promise for the
> > scratch space.
> 
> It works only for people who are familiar with computer and have a lot of 
> time. It is not acceptable for busy people to consume precious time to decide 
> if each piece of data is important or not. Probably they would just insert 
> all data to "important data".

But that wouldn't fit, because it is too small.  These people seem to be able
to select which parts they want to keep and which they can throw away.  It
should be no problem for them to add an extra category, "delayed throw away",
with unspecified delay.

You seem to suggest that with an administrator, it would be possible to
inspect what's on the disk and remove the parts that are "unimportant".  This
is quite a privacy violation (given that it isn't needed, and people can make
this distinction themselves, as Marcus pointed out).  I think privacy should
only be violated if there's a very good reason for it, and in this case there
isn't.  (Yes, that implies that I think it is a Bad Thing that employers spy
on their employees, and I know that not everyone agrees.)

> > I revoke the network capability for her session.
> 
> This is too violent. What if she does not want to hide everything? For 
> example, if she wants to check a note from an internet cafe?

She did something stupid, and that does usually have unfortunate consequences.
If this is the fastest way to solve it, she probably wants that.  On any other
system, where there isn't such accounting, the only solution would probably be
to throw the whole machine off-line until you have found it.  This sounds much
better to me.  Also, the administrator probably _does_ have the right to add
restrictions to the webserver in real-time, which could be to ignore all her
stuff.

The problem with such vague descriptions of the problem as she gives is that
very crude measures are needed if you want to solve them.  For this, it does
not matter what system you work on.

> > If she doesn't remember her password later-on, you will have to kill
> > the session anyway.
> 
> She might be able to remind herself of the password when she comes back and 
> sits down in front of the computer. This is called "associated memory".

Also known as "writing your password on your monitor with a permanent marker".
;-)

> > But here is the important thing: Of course you _could_ also implement
> > backdoors for the administrator into the user sessions.  This option
> > is there.  You can always make a system less secure by introducing
> > more capabilities.
> >
> > The important thing is that you can also not do it, and choose the
> > "paranoid" scenario.  The reverse is not possible.  An insecure system
> > is insecure is insecure.
> 
> I know. What I meant was that a supervisor is required or too useful to be 
> disabled in many situations. I can think of many more examples (e.g. 
> system-wide backup), so I bet that nearly all users would choose to have a 
> supervisor with exchange of a certain amount of security. This is one reason 
> why I feel that security paranoia is too expensive, because very little 
> people use such an extreme configuration.

I wouldn't be to sure about that.  Most machines will be single-user anyway,
so the user, who has access to the administrator capability and his personal
capability, doesn't actually gain many capabilities from the backdoors.

The only thing you can really do with a superuser is violate privacy.
Anything which is useful to be run-time configurable should have a capability
to do that, which is available to the appropriate user (which is the
administrator for system services).

A system-wide backup sounds like a nice idea.  It also sounds pretty trivial
on a persistent system, where you have a checkpoint every few minutes anyway.
It would be useful to add backup functionality to the hard disk driver, and I
don't think a privacy-invading backdoor is needed for that (well, except if
you consider making a backup a privcy-invasion of course :-) ).

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]