l4-hurd
[Top][All Lists]
Advanced

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

Re: The Perils of Pluggability


From: Ludovic Courtès
Subject: Re: The Perils of Pluggability
Date: Mon, 10 Oct 2005 11:06:21 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Hi,

"Jonathan S. Shapiro" <address@hidden> writes:

> Yes. I had some of this discussion with Neal and Marcus at LSM. The
> problem with this design goal is that it is unachievable in a robust or
> secure system. I understand that it is not a goal for Hurd to be secure
> in the sense that Coyotos tries to be, but if you achieve your goal
> above you will manage to be *insecure* in the way that Windows is. We do
> not need another Windows in the world.

Microkernel-based multi-server systems are all about "plugability" and
flexibility, especially the Hurd:
http://www.gnu.org/software/hurd/hurd.html .

Users should be able to run any filesystem server that is part of the
Hurd (e.g. one can "mount" a CD-ROM or an NFS partition without
compromising the stability of the system).

Users should also be able to run third party servers (e.g. one can
download a filesystem server implemented by an unknown hacker, compile
it, run it, and use it, even if the system's administrator doesn't like
it).  When doing so, users have to be aware of whether/how risky it is
to run this code.  Here, whether the suspected program is a server or a
"regular application" makes no difference.

Fortunately, the libre software world comes with some sort of a
"reputation mechanism" which allows users to get an idea of how much
trust they can put in a program.  And this is far superior than
centralized program certification systems (think of "trusted
computing"...) where there's actually a single point of trust: the
company which certifies programs.

[...]

> There are many cases during system development where we rely on plugable
> component interfaces. These are a special case, because they occur in an
> environment of zero vulnerability.

I remember your saying at LSM that Emacs-like extensible systems are
"bad" in that they may have easily-exploitable vulnerabilities.  I'd
like to note two things:

1. In the case of Emacs, I'm not aware of any malicious use of
   modelines, and I'm not aware of any other way to execute code in the
   user's back;

2. extensibility and flexibility have always been an important goal for
   GNU Project's programs, as a way to give users more freedom;  as a
   user, I appreciate it.

IOW, security is good but beware of "securitarianism".  ;-)
Extensibility is not a synonym of vulnerability.  Additionally,
"security" should not serve as a buzzword in favor of non-extensible
monolithic designs.

Thanks,
Ludovic.




reply via email to

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