Re: A niche for the Hurd - next step: reality check

[Michal Suchanek]

2008/11/18  <olafBuddenhagen@gmx.net>:
> Hi,
>
> On Thu, Nov 13, 2008 at 10:11:32AM +0100, Michal Suchanek wrote:
>> 2008/10/29  <olafBuddenhagen@gmx.net>:
>
>> > Perhaps the biggest difference is that on Linux, even with FUSE,
>> > users are limited to a fixed set of trusted filesystems provided by
>> > root. On the Hurd, a user can mount *any* filesystem, no matter
>> > where he got the translator from.
>>
>> Not really.
> [...]
>> I did not need to be root to test my FUSE filesystem
>
> Indeed, it turns out that arbitrary FUSE modules can be mounted, once
> the user is part of the "fuse" group -- so the barrier isn't very high
> in practice. Some clueless person had told me that it wasn't possible...
>
> However, while reading up of FUSE, I found another advantage of Hurd
> translators: There is no need to prevent suid binaries or device files.
> The Hurd security concept makes sure that a filesystem can never give
> the client any privileges the mounting user doesn't have.
>
>> > This of course also fits under lightweight virtualization.
>>
>> Virtualization is the current hype because it is used instead of
>> security and reliability in the system.
>
> It is one of the reasons, yes.
>
>> There are quite a few solutions with various degrees of weight, and
>> some aren't extremely heavy. However, they are mostly restricted to
>> full emulation (slow) or specific hardware features (x86).
>
> Have you read the blog entry I linked somewhere earlier in this thread?
>
>   
> http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html
>
> I touched on all these aspects in there...
>
>> >> If most systems just differ by the translators setup on them,
>> >> people could even transfer their whole environment from one
>> >> computer to another one without needing root access or more root
>> >> interaction than creating a new user account. "I want my tools" ->
>> >> "no problem, just setup your translators".
>
>> How is this easier than carrying around an eeepc/olpc?
>
> The obvious advantage is that you don't need any big and complicated
> hardware -- just a dumb data carrier, or even just a network connection.
>
> Also, using your own hardware is not always possible and/or allowed.
>
> Last but not least, if you have other systems as well, keeping the
> environments in sync is much harder than if you just use the *same*
> environment everywhere.
>
>> I understand a flash drive could be lighter but you can just boot from
>> the flash drive on bare hardware or in full virtualization - i do not
>> see what the Hurd can bring here.
>
> Also not always possible/allowed, and less efficient and convenient.
>
>> Since networking or drive access is possible you can still access
>> resources available from the system.
>
> Possible, but often awkward.
>
> Of course the alternatives you are proposing (carrying own hardware, or
> carrying a medium with a whole system image) each have their own unique
> advantages as well.
>
> Really, you are comparing apples to chocolate bars here.
>
>> And if you run sparc and you come to a ppc you are out of luck anyway
>
> We explicitely discussed the fact that you might need to compile your
> own translators on the host system, unless using translators written in
> interpreted or JIT-compiled languages.
>
> I *never* suggested carrying around compiled binaries -- this just
> doesn't make sense in a free software environment.
>
>> > So for a while some Hurd developers were contemplating a system
>> > based partially on Coyotos, and quite similar to Coyotos in fact.
>> > However, while such a highly secure system might be a good niche, it
>> > would have little to do with the Hurd really. After a while they
>> > realized that this is not quite the right direction, and gave up on
>> > the idea.
>>
>> If I understand it correctly the problem here is not the high security
>> but the fact that the security model of the Coyotos system allows
>> effective DRM (Digital Rights Management).
>
> It's not that Coyotos incidentally allows effective DRM. The problem is
> that Coyotos is fundamentally *designed* to support this kind of use
> cases.
>
> The whole phisosophy behind Coyotos is in direct conflict with GNU
> philosophy, and consequently the design is fundamentally incompatible
> with our goals. This is the conclusion Marcus finally arrived at, and
> IIRC tried to express in his latest posts in the hurd-l4 Coyotos
> discussions.
>
>> There is no viable alternative, though.
>>
>> The L4sec which also focuses on exploring security options is probably
>> not going to be finished anytime soon.
>
> FWIW, there is also seL4, which is more or less production-ready AIUI...
>
> But that's beside the point really. The true alternative is writing our
> own microkernel, implementing just what we really need.
>
> If there is one thing to be learned from the troubles with Mach, then
> L4, then L4ng/L4.sec, and finally Coyotos, it is this: Trying to build
> our own system on top of some existing microkernel just doesn't work.
>
>> > All the time I was convinced that if not going to such extremes as
>> > Coyotos -- implementing POLA throughout the system -- but instead
>> > only trying to confine some of the most dangerous applications, this
>> > could be implemented quite well on the existing Hurd.
>>
>> The problem is that any application is equally dangerous. When your
>> PNG library has a buffer overflow a virus can be carried by otherwise
>> normal looking picture. Now if you consider your browser dangerous and
>> enclose into a subhurd you can still download the image, and view it
>> with a viewer that is not enclosed and also links to the broken
>> library.
>
> Considering how incredibly many security exploits have been found in all
> kinds of multimedia decoders over the past years, you can bet that I'd
> consider image viewers and video players (and pdf readers too) among the
> most dangerous applications.
>
> I see little reason to confine ls or rm, on the other hand.
>
> Security is never all-or-nothing. There is a lot of middle ground
> between traditional UNIX and Coyotos, and some of this middle ground is
> what I am interested in.

Yes, security is never all. Completely secure system cannot be
accessed. And the thing behind UNIX permission was certainly something
like "There could be better security but it's too hard so we will do
at least something".
Still you should get as much security as practical because you never
know in advance what is a threat, and it's the default barriers on
which you rely for mitigating yet unidentified threats. The UNIX
concept simply does not make security practical. Or at least I have
not seen an extension to it that does.

Thanks

Michal