Re: Niches for the Hurd: evaluation method; was: DRM musings, capabilities and stuff

[Arne Babenhauserheide]

Am Freitag 05 Dezember 2008 12:40:32 schrieb Michal Suchanek:
> > And more importantly: There is the root account which can install a
> > libpng version without the weakness.
>
> Fixing the hole after your system was compromised does not help you.

But it helps everyone else. 

> > Currently the security works by fixing found secuirty holes, and it would
> > be nicer if their effect could be reduced.
> >
> > But once a virus gets some systems with the hole, that hole will be found
> > and fixed quite quickly, so a mass-exploit is unlikely.
>
> No, mass-exploits do happen. The only requirement for mass exploit is
> massive user base.

You forgot the requirement that the hole must be open long enough to reach all 
users with the hole. 

> >> Currently you can. There is no effective DRM to date as far as I know,
> >> at least for desktop systems.
> >
> > Windows Vista?
>
> No, you can defeat windows vista security.
>
> They did implement some features that complicate things for the user
> but do not stop an advanced user or hacker.

I thought it  wasstrong enough - but they we still have some time to push them 
back. 

And I'd say, they don't yet. Sadly from what I learned, they are on a way 
towards working DRM, with a whole set of restricted periphery tools. 

> > The virus doesn't have root access (unless I grow very dumb), so it
> > doesn't have the means I have.
>
> if it breaks into your account it can eventually get root access as
> well because you do use root access to set up things, and there isn't
> really any security in place to prevent the virus from accessing
> everything you access.

For that it has to remain undetected long enough. 

> > I don't have 100x the memory I need for running a firefox, but firefox
> > only fires many small system tasks, and for those I have 100x the memory.
>
> For me firefox can cause my media player to skip. This is because
> firefox eats all available CPU time from time to time, and the only
> way to prevent it from interfering with the player would be to elevate
> the player's sheduling priority. This can be done only as root, and
> would prove disastrous if there was a bug in the player which caused
> it to run in a tight loop.
>
> It's not like I have an ancient system or Firefox really needs all the
> system resources to run - there just isn't any reasonable CPU time
> accounting in Linux.

Please don't jump from "it can be done without needing a DRM capable 
structure" towards Linux bashing. 

I know I'm also prone to jumping, but let's try to avoid it for this 
discussion. 

Firefox' resource usage can be controlled without the user having to give up 
access to its memory, and system servers started and controlled by root could 
just police themselves. 

> > The admin gives the user a pool of system memory he can use for any task.
>
> So this is like DRM except you cannot turn DRM memory into non-DRM
> memory and the other way around.
> You just get a piece of plain memory and a piece of DRM memory.

No. 

It isn't DRM memory, because the admin always has access to it. 

> > (I don't say "secure" here - what I need is fair resource accounting, not
> > secure resource accounting).
>
> If it is not secure you cannot ensure it is fair either.

Ensure is a strong word. 

Security says "this has to work in all cases". Else they call it a security 
hole. 

Fariness just needs to say "This works as intended in most situations, and the 
other few situations aren't noticeable". 

That way "fair" gives you far more options than "secure". 

> > So the level of security is useless for most users, but the danger is
> > furthering a DRM ridden society.
> >
> > (sorry if that sounds too hard - it's the trade I currently see).
>
> You are mixing up things. To make society DRM ridden you must
> implement the verification that is required for adding "trust" to
> otherwise untrusted relationships between computer systems.

If you facilitate implementing that verification, you further a DRM ridden 
society. 

That's called the "invisible hand". Many do small things, and since noone had 
the foresight to see where he was heading, there was Hiroshima in the end. 

DIfferent from those nuclear physics scientists, we see the thread today, and  
acting or not acting upon that knowledge is our responsibility. 

> useless until somebody shows an example where it adds any value but
> that does not discard the utility of security.

Value to whom? 

> > And why should I allow such a component in my free system.
>
> Then run Windows 95. They do not have any security whatsoever so they
> will fulfill this desire of yours.

You really suggest to me using Windows 95? 

I said "free system", and free is not proprietary and definitely not WIndows. 

> some security, and a third party that the DRM content provider trusts

That's exactly what you say: You want others to be able to trust my computer. 
But then I can't trust my computer anymore to do what I tell it. 

I want to trust it, I don't want others to be able to trust it if they don't 
trust me. 

> > And once programmers start using that convenience layer, you're in the
> > same position again, but now with a layer which is incompatible to most
> > applications.
>
> So if something can be entered by the user it is a compatibility layer?

As soon as you have to design a simplification layer, you have a kind of 
compatibility layer - only with the disadvantage that there aren't any 
compatible applications, yet. 

Do you trust the designers of that system so much as to think that their 
design will do better than POSIX on the long run? 

> > I'm sure that POSIX has weaknesses. But how do you make sure that your
> > convenience layer wouldn't have just as many weaknesses which only show
> > later on?
>
> Then it can be changed. It's only an interface for the user to enter
> something in a terminal.
> You are speaking as if there was only single shell used throughout all
> UNIX systems.

No. I just take into account that many scripts will use your simplification 
layer,so it will become a kind of API, and more and more applications will 
depend on a certain version of it. 

> Not using separate processes gives very poor reliability. Never had
> your browser crash because of a plugin?

So we are now talking redesigning most applications. 

> > But I do think that porting to the Hurd should prove quite a bit easier
> > than porting to a system without POSIX layer.
>
> Why so? There's nothing stopping you from adding libposix into the
> system that implements the posix interfaces commonly used by
> applications that would be missing otherwise.

Will you supply the libposix, or do I have to write it myself? 

And if it's there, how many programs will just use that? 

> > The Hurd gives me as user the option of working on a very low level
> > without having to be root (which also means avoiding all the dangers of
> > being root, including shooting down my system).
>
> There are actually very few things that you can safely work on in the
> Hurd but not in Linux.

I'll leave this one out. Olaf already explained it quite nicely. No need to 
try and find new words for that myself. 

> There are actually some which you can do in Linux but not in Hurd as
> GNU Mach does not have userspace drivers AFAIK.

A (userspace) translator can do exactly that - as long as the really low level 
part is done in the kernel. 

> > But it isn't used in most applications. Most programs still use internal
> > editors and stuff, because that's the easier way to implement them.
>
> No, it's not easier.  It's just reinventing the wheel, all the way
> from square wheel to semi-rounded one.

Then why do so many people do it? 

> > And I don't know how hard it is for applications to directly access the
> > capability layer in the Hurd (bypassing the POSIX layer), so I can't say
> > if the second layer isn't optional as well.
>
> If you make the POSIX layer optional then you make a sytem based on
> capabilities, and that's what I wanted in the first place.
> That's not how the current Hurd looks like, though.

I'll leave this one for Olaf as well. 

> > So what keeps him from just modifying that first process to give him
> > power again?
>
> Nothing. However, if particular version of the system were verified
> for use with DRM protected content modifying that process would void
> that verification.

And who keeps me from modifying the routinee h uses for checking the 
verification? 

> > It would be far easier to just assign a second-level admin (system
> > manager) who doesn't have this right but keep root access as it is.
>
> The use of non-free crypto devices is the only way how a society might
> become DRM-ridden (otherwise the protection can be bypassed). However,
> using such device to verify your system might become the requirement
> for access to some services.

Especially if many people aid in creating systems which make it easy to use 
that kind of digital slavery. 

Not me, thanks. 

> > But for me it seems that the patching and porting would be far more work
> > on a system without POSIX layer.
>
> Where does KDE deal with POSIX?

To take the simplest example: User management. 

> > The translators are transparent to the mail client, so I can still change
> > my system layout with them even though the Mail program doesn't see them.
> >
> > So they still offer an advantage.
>
> There is no reason why the situation with capabilities should be different.
>
> However, from your answers it looks like you know little about
> software and system management, let alone writing software so I
> suggest you look into that before we continue the debate about
> feasibility of porting software to one kind of system or another.

I know less about coding than an experienced programmer (I only write programs 
for a bit more than a year now), and my system management is limited to about 
5 years of experience with Gentoo and university courses which sum up to about 
2/3rd of a bachlor in informatics (I'm studying physics, and I learned stuff 
like high performance cluster file systems simply because it interested me, 
not because I needed it). 

(there's a reason why I do web editing for the Hurd and not lowlevel 
programming)

But I know that just the changes Gentoo ebuilds make to get programs running 
in the environment they are designed for can become quite mmuch work, and I 
get the impression of quite much pain when I think about porting nontrivial 
stuff to a pure capabilities system. 

But I let myself get sidetracked, and I'm sorry about that. 

The discussion was about DRM and why Coyotos isn't suited to be a kernel for 
the Hurd because it is designed to allow for effective DRM. 

You want others to be able to trust my computer. But then I can't trust it 
anymore to do what I tell it. 

I want to trust my computer. I don't want others to be able to trust it if 
they don't trust me. 

Best wishes, 
Arne
-- 
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.