Digest of the offlist discussion on DRM, Coyotos and the Hurd

[Arne Babenhauserheide]

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: DRM musings, capabilities and stuff
Datum: Mittwoch 26 November 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>


2008/11/25 Arne Babenhauserheide <arne_bab@web.de>:
> Am Dienstag 25 November 2008 01:11:05 schrieb Michal Suchanek:
>> > "Sorry, you are only allowed to cut Sony bread with Sony-licensed
>> > knives".
>> >
>> > Sounds quite evil, doesn't it?
>>
>> Yes. It does.
>> And the question for which I do not know the answer is:
>> Can you design a knife that cannot be made to not cut Sony bread
>> unless Sony lincensed?
>
> There are already knives that cannot _easily_ be turned into that.

Really? Ones so blunt they cannot cut anything at all?
Then they will surely never be the knives to cut only Sony bread :->

>> I want security for the user. The only system that promises to offer
>> it also promises to offer security against the user.
>> There is slight difference in the concepts and it is not obvious if
>> creating tools that support security for the user is possible without
>> making them usable for security against the user.
>
> Let's go to the simple point: I am setting up a system with standard
> applications. Then I install a new program.
>
> If I use Coyotos: Can that program do DRM stuff which I can't control?

No. But if you do not allow it to do DRM it may refuse to do anything at all.
Once you allow it to do DRM there is stuff that you can no longer
access unless the program allows you to do so..

>
>> Not necessarily. DRM is about protecting information, and so is
>> security. It would require very careful thinking to craft a system
>> that is secure and does not support DRM.
>
> It doesn't have to be unable to support DRM (Linux could be changed to 
support
> DRM, too), it just mustn't be too easy to just turn on DRM to lock in the
> user.

Linux cannot be made to support good DRM. It's so huge and buggy that
you could most likely defeat the DRM protection one way or another.

[...]
>
>> One simple thing is when the administrator gives you memory that
>> nobody else can access unless you give them capability for some part
>> of the memory. The problem is that if you request a service from a
>> system server you should provide the memory the service requires, and
>> it is not apparent if it is good idea that you can read that memory at
>> any time. And if you cannot you got DRM.
>
> Do you mean "If a new process gets spawned for that i need to provide the
> memory"?
>
> I think that any system process which doesn't want to use "my" memory should
> just already have its own memory.

This is not such a good idea. It limits the user choice. Imagine you
want some transactions performed by a system service such as sending
IP datagrams.

Then either you provide the resources for the service to preform the
transactions, or the service has to run off its own resources provided
by the administrator.

In the later case the service might have too few resources to perform
as many transactions as you would wish, your use of the service might
degrade it for another user, or the other way around.

So you ask the administrator to give more resources to the service.
Then it holds them even when you could use them for something else. If
they were allocated dynamically, which seems very questionable from a
security point of view, then another user could cause degradation of
other services for you by requesting many transactions and causing
allocation of lots of resources for sending IP datagrams.

You could certainly run your own IP stack but in the end you get to
DMA buffers of some PCI controller which have to be managed by the
system for security reasons and stored in memory while the
transmission is in progress.

>
> But I'm no specialist in security, so I can't go much deeper on this.
>
>> Also when the administrator cannot access your memory you got DRM.
>>
>> So DRM can give power to anybody, including you. The problem with DRM
>> is that it is far more likely to concentrate power for those who have
>> way too much already than it is going to help you defend against them,
>> alhough technically it has the potential for both.
>
> I think we need to clear up wording here.
>
> DRM in its original meaning is a real "rights management".
>
> I as user can decide what happens to my stuff.
>
> I wouldn't say that this is a bad thing.
>
> What it's been turned into can be summarized as "it's your computer, but we
> say what it can do", and that is essentially a hostile takeover of my
> property.
>
> It is like taking the initial idea "everyone should control his own stuff" 
and
> broadening it into "everyone should control his stuff, wherever it is, even
> when it is on some other persons computer", then thinking that further and
> realizing that complete control can only be archieved by controlling the
> computer of all other people as well as your own.
>
> It means taking something normally good to an extreme where it suddenly
> becomes where dangerous.
>
>
> Which of those uses of DRM does Coyotos really make easy?

DRM is about verifying with some degree of credibility that a piece of
information is not accessible to anyone else.

That allows you to check with some degree of credibility that your
memory is not accessible to the administrator (although the
administrator should keep the capability to revoke your use of the
memory in case your account is terminated).

Similarly a program downloaded from the internet to play protected
content can use the same guarantee to ensure you cannot freely access
the content it protects. You can remove the program and the content
whenever you wish but you cannot access it.

If you could the program would find out using some OS service and
would not allow you to download or store any protected content in the
first place.

Security is about verifying that when you are running programs A and B
they cannot access the memory of each other. If you cannot do that
virii can spread like fire through your system, and in practice they
do.

However, on a secure system the system pager that backs all system
memory can provide a protected memory service - it revokes your right
to use a part of your memory and gives you a revoke capability
instead. The pager can now verify that you cannot access the memory
anymore, and provide the guarantee to a third party that uses the
memory to provide a (dis)service to you. When you are fed up with it
you use the revoke capability and get your memory back full of nice
shiny clean zeroes.

You need not provide such service but it seems adding it to a system
with non-trivial security is not very difficult (although it makes the
core system slightly more complex).

[...]

>> A capability gives a process access to a resource or service provided
>> by the system - such as a piece of storage, a slice of CPU time,
>> access to the network. a directory of other capabilities, etc.
>
> How can I as user provide them (in a practical example)?
>
> Do I say
>
> $ run_app --capabilities{read:/home/user/subdir/,write:/home/user/subdir} 
APP
>
> Or how else do I go at it?

In KDE you would most likely run something like kwrite which would be
set up to have access to the KDE configuration so that it knows which
colour you like your buttons.

Then you can either write a document from scratch or use the Open
dialog which would be the service provided by user shell to grant
capabilities to applications.

As the Open dialog is typically a stock control in GUI toolkits
replacing it should be easy.

I have no idea how capabilities would be conveniently expressed when
running programs from the command line.
You can probably script the above and come with some syntax that is
easier to write.

However, if you run

$ kwrite myfile.doc

the shell might assume you want kwrite access the file myfile.doc in
addition to the KDE configuration but it's certainly suboptimal for
programs with more complex arguments.

>
>> Only when you send mail. Ideally it would have a separate composer but
>> it should not be that hard to just run a separate instance for sending
>> a mail.
>
> That looks like quite much additional design work. I assume that instead 
many
> programmers will just get lazy and say "this is part of the mail app, so it
> should have all needed capabilities".

Current mail programs do not have such feature but they could be
packaged so that a separate instance of the same program is used for
sending mail if you wished so.

Note also that mail clients like mutt use external editors to compose
email which is not very far from using a completely separate send
program.

>
>> > * can show different file types,
>>
>> It can use specialized viewers for that, many mail programs do that anyway.
>
> But many others don't. Should all of them be redesigned or abolished for the
> sake of using the capability system?

They should be redesigned or abolished simply for the sake of
reliability and security, not for the sake of a capability system.

>
>> > * can open files from anywhere on my disk (for attaching) and
>>
>> Only when you manually attach them so you can just make it call the
>> file selector that gives it the capability in this case.
>
> Does that mean calling another process or just a thread with added
> capabilities?

A thread as understood in, say, pthreads is not secure. It can access
the memory of other threads. You need the equivalent of a new process
running under a different account.

>
>> You need deep rewrite (or replacement) of the system in the first
>> place. Then you can slightly modify some existing applications to
>> improve their security or wrap them in some compatibility layer. And
>> write new applications that make full use of the possible security.
>
> Where is the difference between using a capability layer and using the POSIX
> layer in the Hurd?

The difference is that a system with fewer different layers and
incompatible concepts is easier to understand and manage.

Many concepts in CS or math are equivalent but some problems are
easier to express and understand using different concepts.

>
>> > > As the multiple-mail followup suggests adding sound security into UID
>> > > based system is very difficult at best, and hard to get right.
>> >
>> > "You discussed for a long time, so your result must be weak".
>> >
>> > That reasoning is very questionable.
>>
>> No, you had to iterate several times to get it right with the current
>> system because it is quite impractical and error-prone to do so, or so
>> it seems.
>
> In my case the reason for taking some more time was simply, that i didn't 
know
> how Hurd handled adding and removing UIDs before the discussion, so I had to
> ask a few times.
>
> Or do you mean some long discussion I didn't take part in?

I did not say "long".

Either way it might be just the wrong impression.

>
>> > No way he can access shadow or similar with just my permissions.
>>
>> The attacker can read you bank account information, your address book,
>> all your documents (some of which you might not want to publically
>> disclose), and whatnot.
>
> My Bank account information is encrypted - he can't see that without giving 
my
> KDE wallet my password.

It is decrypted at some point if you can view/use it.
[..]
>
>> You can see all the system applications, and if some is at version
>> that is vulnerable it is possible to see it immediately.
>> Same if you misconfigured one of your applications so that it can be
>> used as a backdoor.
>> You give away information easily that the attacker would have to learn
>> through tedious experimentation or would not learn at all before it
>> becomes obsolete (like before the system is upgraded or reconfigured).
>
> But this also means that i have to specify that read access for every
> application, including any possible future use, doesn't it?
>
>> > If A contains "b" then read B, if not read C.
>> >
>> > Next action is a logical question, not a technical one.
>>
>> Is there a real world example?
>
> $ hg update # Mercurial version tracking, update the working directory
>
> -> reads the manifest file, then reads the store files in question, then 
reads
> and writes to repository files. The subscription extension also offers the
> option of using an external config file which may be anywhere on the system.

I don't know what is subscription extension.

Under normal circumstances hg works on a repository (not sure how
exactly is each part called, there is the working dir, and the dir
with version tracking information) which is a bunch of related files
so you can just give hg access to the repository.

I guess it would be also desirable to find a convenient way to pack
access to the upstream server with the repository.

>
> [snip stuff that antrik answered plud the KDE beginning]
>
>> I am sure that there are some interesting design decisions that would
>> make porting any desktop environment challenging.
>
> But the Hurd actually intends to make it possible to run KDE out of the box
> once development is there (that will be the point when I can start using teh
> Hurd as production system).

Since when does the Hurd plan to implement a Linux binary
compatibility layer? This is big news to me.

Otherwise there are some design decisions in the Hurd that make
porting POSIX applications somewhat challenging.
It does not implement some optional parts of POSIX which break *a lot*
of applications. For one it does not define MAXPATHLEN and similar
constants which are widely abused by POSIX "compatible" software.

However. even if you compile KDE on the Hurd and fix up all the
deficiencies in the Hurd and KDE that make them incompatible the KDE
would perform the same as it does on Linux. To make use of the
translators you would have to further modify it. Sure, you can step
outside of KDE and set up the translators in a terminal but that is
not unlike running KDE inside a POSIX compatibility layer on a system
that is otherwise design around capabilities.

>
> A capability system doesn't do that.
How so?

>
> [snip]
>
>> > Sure, using filters, so it ignores the access translators below it (see
>> > Sergius work).
>>
>> Nice. So you take a kernel that implements capabilities, then put a
>> layer that implements sort of POSIX permissions on top of that, and
>> then add sort of weak capabilities on top of that again. I fail to see
>> how this is easier to use or understand than the same setup with the
>> middle layer removed.
>
> The middle layer adds the ability to run any POSIX program. The translators
> allow harnessing the power of the capability system in a way which is
> transparent to the applications.

You can run POSIX programs without contaminating the whole system with
POSIX, even for native applications.

[...]
>> > Linux has hundreds of kernel developers. The Hurd has about 5.
>
>> And it will stay so until people see a compelling reason to look at the
>> Hurd.
>
> This is your thinking and I'm sure it is based on things you experienced.
>
> It implies that the Hurd has nothing compelling to offer, and I think you're
> wrong with that thought, because you ignore one important point: Core
> information about the Hurd wasn't easily available for quite a long time. 
The
> wiki and now the relocating of the wiki to be the mainw ebsite changed that.
>
> Three years ago I searched in vain for information on what was happening
> around the Hurd at that moment.
>
> Now that information is readily available.
>
> But ignoring what the sentence implies, it is mostly true: It will stay that
> way until people _see_ the compelling reasons to look at the Hurd.
>
> I hope that the new website structure helps them to see that, along with the
> successes of the GSoC projects.

I know there are things that are interesting about the Hurd. But there
are also interesting things about the BSDs and people aren't rushing
for them either. This is because there is inherent difficulty in
running less mainstream system - at least with current system design,
and it is not outweighted by the advantages the system provides in
most cases.

>
>> I was running it on my desktop machine for a year or so until I
>> decided there is no point in keeping it.
>
> Then please excuse my unfounded words.
>
> I thought that speaking what I think would be more useful than avoiding 
that.
No problem

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: DRM musings, capabilities and stuff
Datum: Dienstag 25 November 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Am Dienstag 25 November 2008 01:11:05 schrieb Michal Suchanek:
> > "Sorry, you are only allowed to cut Sony bread with Sony-licensed
> > knives".
> >
> > Sounds quite evil, doesn't it?
>
> Yes. It does.
> And the question for which I do not know the answer is:
> Can you design a knife that cannot be made to not cut Sony bread
> unless Sony lincensed?

There are already knives that cannot _easily_ be turned into that. 

In contrast from what I read till now, Coyotos is designed in a way which will 
make it very easy to turn it against the user (me). 

If something is possible, chances are high that it will eventually be done. If 
something is extremely easy, chances are high that it will be done in 
mainstream. 

> I want security for the user. The only system that promises to offer
> it also promises to offer security against the user.
> There is slight difference in the concepts and it is not obvious if
> creating tools that support security for the user is possible without
> making them usable for security against the user.

Let's go to the simple point: I am setting up a system with standard 
applications. Then I install a new program. 

If I use Coyotos: Can that program do DRM stuff which I can't control? 

> Not necessarily. DRM is about protecting information, and so is
> security. It would require very careful thinking to craft a system
> that is secure and does not support DRM.

It doesn't have to be unable to support DRM (Linux could be changed to support 
DRM, too), it just mustn't be too easy to just turn on DRM to lock in the 
user. 

And I as user have to have the final say about what happens with the memory 
assigned to me, as long as the admin doesn't decide otherwise. 

> One simple thing is when the administrator gives you memory that
> nobody else can access unless you give them capability for some part
> of the memory. The problem is that if you request a service from a
> system server you should provide the memory the service requires, and
> it is not apparent if it is good idea that you can read that memory at
> any time. And if you cannot you got DRM.

Do you mean "If a new process gets spawned for that i need to provide the 
memory"? 

I think that any system process which doesn't want to use "my" memory should 
just already have its own memory. 

But I'm no specialist in security, so I can't go much deeper on this. 

> Also when the administrator cannot access your memory you got DRM.
>
> So DRM can give power to anybody, including you. The problem with DRM
> is that it is far more likely to concentrate power for those who have
> way too much already than it is going to help you defend against them,
> alhough technically it has the potential for both.

I think we need to clear up wording here. 

DRM in its original meaning is a real "rights management". 

I as user can decide what happens to my stuff. 

I wouldn't say that this is a bad thing. 

What it's been turned into can be summarized as "it's your computer, but we 
say what it can do", and that is essentially a hostile takeover of my 
property. 

It is like taking the initial idea "everyone should control his own stuff" and 
broadening it into "everyone should control his stuff, wherever it is, even 
when it is on some other persons computer", then thinking that further and 
realizing that complete control can only be archieved by controlling the 
computer of all other people as well as your own. 

It means taking something normally good to an extreme where it suddenly 
becomes where dangerous. 


Which of those uses of DRM does Coyotos really make easy? 

> Yes, that's the point I am trying to make. There are users who do not
> care about the underlying concept, and they will not care whatever it
> will be. And there are users who *should* care about it - like writers
> of software that requires some security or system administrators. And
> these should see the system clearly, not veiled in some
> half-compatible POSIX facade.

[snip]

> You just said they will not care so why are you saying they will not use it
> now?

[snip]

> I am sure they will also stumble over the "hidden capabilities".

[snip]

I think antrik answered the points above far better than I could, so I'll just 
keep my mouth shut to avoid muddling up the discussion here. . 

> A capability gives a process access to a resource or service provided
> by the system - such as a piece of storage, a slice of CPU time,
> access to the network. a directory of other capabilities, etc.

How can I as user provide them (in a practical example)? 

Do I say 

$ run_app --capabilities{read:/home/user/subdir/,write:/home/user/subdir} APP

Or how else do I go at it? 

> Only when you send mail. Ideally it would have a separate composer but
> it should not be that hard to just run a separate instance for sending
> a mail.

That looks like quite much additional design work. I assume that instead many 
programmers will just get lazy and say "this is part of the mail app, so it 
should have all needed capabilities". 

> > * can show different file types,
>
> It can use specialized viewers for that, many mail programs do that anyway.

But many others don't. Should all of them be redesigned or abolished for the 
sake of using the capability system? 

> > * can open files from anywhere on my disk (for attaching) and
>
> Only when you manually attach them so you can just make it call the
> file selector that gives it the capability in this case.

Does that mean calling another process or just a thread with added 
capabilities? 

> You need deep rewrite (or replacement) of the system in the first
> place. Then you can slightly modify some existing applications to
> improve their security or wrap them in some compatibility layer. And
> write new applications that make full use of the possible security.

Where is the difference between using a capability layer and using the POSIX 
layer in the Hurd? 

> > > As the multiple-mail followup suggests adding sound security into UID
> > > based system is very difficult at best, and hard to get right.
> >
> > "You discussed for a long time, so your result must be weak".
> >
> > That reasoning is very questionable.
>
> No, you had to iterate several times to get it right with the current
> system because it is quite impractical and error-prone to do so, or so
> it seems.

In my case the reason for taking some more time was simply, that i didn't know 
how Hurd handled adding and removing UIDs before the discussion, so I had to 
ask a few times. 

Or do you mean some long discussion I didn't take part in? 

> > No way he can access shadow or similar with just my permissions.
>
> The attacker can read you bank account information, your address book,
> all your documents (some of which you might not want to publically
> disclose), and whatnot.

My Bank account information is encrypted - he can't see that without giving my 
KDE wallet my password. 
For the rest: yes. He managed to get read access. 

> You can see all the system applications, and if some is at version
> that is vulnerable it is possible to see it immediately.
> Same if you misconfigured one of your applications so that it can be
> used as a backdoor.
> You give away information easily that the attacker would have to learn
> through tedious experimentation or would not learn at all before it
> becomes obsolete (like before the system is upgraded or reconfigured).

But this also means that i have to specify that read access for every 
application, including any possible future use, doesn't it? 

> > If A contains "b" then read B, if not read C.
> >
> > Next action is a logical question, not a technical one.
>
> Is there a real world example?

$ hg update # Mercurial version tracking, update the working directory

-> reads the manifest file, then reads the store files in question, then reads 
and writes to repository files. The subscription extension also offers the 
option of using an external config file which may be anywhere on the system. 

[snip stuff that antrik answered plud the KDE beginning]

> I am sure that there are some interesting design decisions that would
> make porting any desktop environment challenging.

But the Hurd actually intends to make it possible to run KDE out of the box 
once development is there (that will be the point when I can start using teh 
Hurd as production system). 

A capability system doesn't do that. 

[snip]

> > Sure, using filters, so it ignores the access translators below it (see
> > Sergius work).
>
> Nice. So you take a kernel that implements capabilities, then put a
> layer that implements sort of POSIX permissions on top of that, and
> then add sort of weak capabilities on top of that again. I fail to see
> how this is easier to use or understand than the same setup with the
> middle layer removed.

The middle layer adds the ability to run any POSIX program. The translators 
allow harnessing the power of the capability system in a way which is 
transparent to the applications. 

> > Aside from not being connected to the earlier line with more than unsure
> > thread, your conclusion misses the glaring obvious point:
>
> It was connected to the previous paragraph which you stripped.

Then I missed that connection - sorry. 

> > Linux has hundreds of kernel developers. The Hurd has about 5.

> And it will stay so until people see a compelling reason to look at the
> Hurd.

This is your thinking and I'm sure it is based on things you experienced. 

It implies that the Hurd has nothing compelling to offer, and I think you're 
wrong with that thought, because you ignore one important point: Core 
information about the Hurd wasn't easily available for quite a long time. The 
wiki and now the relocating of the wiki to be the mainw ebsite changed that. 

Three years ago I searched in vain for information on what was happening 
around the Hurd at that moment. 

Now that information is readily available. 

But ignoring what the sentence implies, it is mostly true: It will stay that 
way until people _see_ the compelling reasons to look at the Hurd. 

I hope that the new website structure helps them to see that, along with the 
successes of the GSoC projects. 

> I was running it on my desktop machine for a year or so until I
> decided there is no point in keeping it.

Then please excuse my unfounded words. 

I thought that speaking what I think would be more useful than avoiding that. 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Donnerstag 27 November 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

...the evaluation part is far down at the end of the Mail... 

Am Mittwoch 26 November 2008 01:08:12 schrieb Michal Suchanek:
> > There are already knives that cannot _easily_ be turned into that.
>
> Really? Ones so blunt they cannot cut anything at all?
> Then they will surely never be the knives to cut only Sony bread :->

Ones that already work. 

For example for writing this E-Mail. 

> > If I use Coyotos: Can that program do DRM stuff which I can't control?
>
> No. But if you do not allow it to do DRM it may refuse to do anything at
> all. Once you allow it to do DRM there is stuff that you can no longer
> access unless the program allows you to do so..

I hope that people will find a way to convince the program that it can do DRM 
while actually not giving it that kind of power - it's still my system after 
all. 

This kind of security might look nice in theory and for some applications, but 
in regular desktop use that's a kind of power I don't want to grant any 
program on my computer (except if I can look into the code and change how it 
works - the free kernel). 

> Linux cannot be made to support good DRM. It's so huge and buggy that
> you could most likely defeat the DRM protection one way or another.

"huge" and "buggy" are just another way of spelling "expensive". 

If that means that i as owner can defeat the DRM _restrictions_, that's not 
that bad for me. 

I don't want to run a multi-user restricted-admin system. I want a desktop 
(just like 90% of the computer users out there), and for that I don't need 
that "good" DRM. 

If you talk about business to business services, that's an entirely different 
matter. 

> In the later case the service might have too few resources to perform
> as many transactions as you would wish, your use of the service might
> degrade it for another user, or the other way around.

How tight must the memory restriction be to have that issue? 

> So you ask the administrator to give more resources to the service.
> Then it holds them even when you could use them for something else. If
> they were allocated dynamically, which seems very questionable from a
> security point of view, then another user could cause degradation of
> other services for you by requesting many transactions and causing
> allocation of lots of resources for sending IP datagrams.

The system resources process could simply have per-user limits. 

> You could certainly run your own IP stack but in the end you get to
> DMA buffers of some PCI controller which have to be managed by the
> system for security reasons and stored in memory while the
> transmission is in progress.

So the simple thing would be to just keep the minimal set which is necessary 
for security reasons under admin control using admin memory. The whole rest 
can be accessed by the user, and there's no need for granting applications use 
of memory I can no longer control. 

Developing a structure for taking away control from the user to solve this 
sounds a bit over the top for me. 

I'm sure there are deeper issues, but as I wrote I can't get into these. 

> > Which of those uses of DRM does Coyotos really make easy?
>
> DRM is about verifying with some degree of credibility that a piece of
> information is not accessible to anyone else.
>
> That allows you to check with some degree of credibility that your
> memory is not accessible to the administrator (although the
> administrator should keep the capability to revoke your use of the
> memory in case your account is terminated).

This is a level of security I don't need. 

In the end I have to trust the administrator, since he could just run a 
modified Coyotos which grants him hidden access to my memory but fakes being 
an unmodified Coyotos. 

So I only gain a false sens of security, which is worse than knowing 
beforehand that i have to trust my admin. 

Except if people plan to sell Coyotos in locked down devices where the admin 
can't change the system. But such a system would then go against my principles 
even more. 

Either it can be changed by the admin (who has or knows someone who has 
sufficient abilities), then any security against the admin is fake security. 
Or it can't be changed by the admin. Then it isn't allowed into my house, 
because it violates the principles of free software. 

> If you could the program would find out using some OS service and
> would not allow you to download or store any protected content in the
> first place.

What keeps me from exchanging these OS routines with fake routines? 

> I have no idea how capabilities would be conveniently expressed when
> running programs from the command line.
> You can probably script the above and come with some syntax that is
> easier to write.

But then we're back at the level of adding convenience layers which is the 
same as offering a POSIX layer, just maybe not backwards compatible. 

> Current mail programs do not have such feature but they could be
> packaged so that a separate instance of the same program is used for
> sending mail if you wished so.

This all sounds like an awful lot of work which could better be spent in 
improving the applications for all systems. 

From what I see in Hurd development, making it possible to run any Linux 
application is done in the Hurd itself, so there's just one central place 
which needs changes. 

Changing every one of the I-don't-know-how-many complexer GUI applications to 
support capabilities sounds like a hell of a lot of more work. 

> > But many others don't. Should all of them be redesigned or abolished for
> > the sake of using the capability system?
>
> They should be redesigned or abolished simply for the sake of
> reliability and security, not for the sake of a capability system.

With that the chances that I'd use such a system are damn low. 

If there's a nice free program out there whoose development stopped in 2006, I 
want to be able to use it. Security means to me in that case, that I should be 
able to just grant the program the rigths it has with little effort. 

It already uses UID and GID based access rights, so I need a POSIX layer. 

> > Does that mean calling another process or just a thread with added
> > capabilities?
>
> A thread as understood in, say, pthreads is not secure. It can access
> the memory of other threads. You need the equivalent of a new process
> running under a different account.

Sounds like a paradigm shift again. People have been using threads for some 
years now - especially in GUIs, and rewriting all that code to inter-process-
communication will be a pain. 

> > Where is the difference between using a capability layer and using the
> > POSIX layer in the Hurd?
>
> The difference is that a system with fewer different layers and
> incompatible concepts is easier to understand and manage.

...once you learned the new language. 

Before that it just isn't usable at all. And people are resistant to 
completely new things. 

So to get many people to use your system, you'll need to wrap it up into a 
layer they know, and we're back at POSIX or something similar but nonstandard. 

> Many concepts in CS or math are equivalent but some problems are
> easier to express and understand using different concepts.

If I want a "pure" mathematician to use my program, it better look like his 
math, else he will use some other program which does. 

The same goes the other way round for programmers. 

> > My Bank account information is encrypted - he can't see that without
> > giving my KDE wallet my password.
>
> It is decrypted at some point if you can view/use it.

Here we are at a point I think: It is decrypted in my memory. If he got root 
access, he could now check my memory (the worst case), but I don't need to be 
able to sign away access rights to some other process to avoid that. 

it's enough to have a tree with lower and lower access rights, with the main 
process sitting at the top with access to all. 

> > $ hg update # Mercurial version tracking, update the working directory
> >
> > -> reads the manifest file, then reads the store files in question, then
> > reads and writes to repository files. The subscription extension also
> > offers the option of using an external config file which may be anywhere
> > on the system.
>
> I don't know what is subscription extension.

Sorry, my mistake - name mangling. I use it for email subscriptions... 

It's name is "NotifyExtension". 

> Under normal circumstances hg works on a repository (not sure how
> exactly is each part called, there is the working dir, and the dir
> with version tracking information) which is a bunch of related files
> so you can just give hg access to the repository.
>
> I guess it would be also desirable to find a convenient way to pack
> access to the upstream server with the repository.

> > But the Hurd actually intends to make it possible to run KDE out of the
> > box once development is there (that will be the point when I can start
> > using teh Hurd as production system).
>
> Since when does the Hurd plan to implement a Linux binary
> compatibility layer? This is big news to me.

I run Gentoo, so I have about two binaries on my system: OpenOffice and 
Firefox :) 

The rest is built from source without needing my interaction, so that's what I 
mean with "out of the box". 

"emerge kde" or "apt-get kde" should suffice for getting it to run. 

> However. even if you compile KDE on the Hurd and fix up all the
> deficiencies in the Hurd and KDE that make them incompatible the KDE
> would perform the same as it does on Linux. To make use of the
> translators you would have to further modify it. Sure, you can step
> outside of KDE and set up the translators in a terminal but that is
> not unlike running KDE inside a POSIX compatibility layer on a system
> that is otherwise design around capabilities.

So you have the POSIX compatibility layer again. 

> > A capability system doesn't do that.
>
> How so?

My lovely little program which is no longer managed won't work, since it uses 
group permissions, for example. 

> > The middle layer adds the ability to run any POSIX program. The
> > translators allow harnessing the power of the capability system in a way
> > which is transparent to the applications.
>
> You can run POSIX programs without contaminating the whole system with
> POSIX, even for native applications.

You can instead offer the standard which most free software programmers know 
today. I wouldn't call POSIX a contamination. 

> [...]
>
> >> > Linux has hundreds of kernel developers. The Hurd has about 5.
> >>
> >> And it will stay so until people see a compelling reason to look at the
> >> Hurd.

[snip]

> I know there are things that are interesting about the Hurd. But there
> are also interesting things about the BSDs and people aren't rushing
> for them either. This is because there is inherent difficulty in
> running less mainstream system - at least with current system design,
> and it is not outweighted by the advantages the system provides in
> most cases.

But pure capability systems are even less mainstream, and they are even harder 
to put to normal use, and ease of running DRM badness on them won't bring many 
free programmers either. 

And I don't care about nonfree software. 

So what the Hurd needs is a niche, where its advantages outwheight the cost of 
using it instead of a GNU/Linux system. 

And here the story archs back to its topicand it brings an evaluation tool 
with it :) 

Evaluation: 
* What is the cost of running a Hurd in the niche? 
* What is the benefit of running a Hurd in the niche? 

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


-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Donnerstag 27 November 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

2008/11/27 Arne Babenhauserheide <arne_bab@web.de>:
> ...the evaluation part is far down at the end of the Mail...
>
> Am Mittwoch 26 November 2008 01:08:12 schrieb Michal Suchanek:
>> > There are already knives that cannot _easily_ be turned into that.
>>
>> Really? Ones so blunt they cannot cut anything at all?
>> Then they will surely never be the knives to cut only Sony bread :->
>
> Ones that already work.
>
> For example for writing this E-Mail.

Yes, it is possible to write emails. And if there were currently a
buffer overflow in libpng and I sent you specially crafted email with
a PNG image I might manage to break into your account, and since it's
a single user system breaking into your account is all that matters -
there is nothing useful beyond your account.

>
>> > If I use Coyotos: Can that program do DRM stuff which I can't control?
>>
>> No. But if you do not allow it to do DRM it may refuse to do anything at
>> all. Once you allow it to do DRM there is stuff that you can no longer
>> access unless the program allows you to do so..
>
> I hope that people will find a way to convince the program that it can do 
DRM
> while actually not giving it that kind of power - it's still my system after
> all.

Currently you can. There is no effective DRM to date as far as I know,
at least for desktop systems.

Some special purpose devices might have sound DRM, though.
[...]
>
>> Linux cannot be made to support good DRM. It's so huge and buggy that
>> you could most likely defeat the DRM protection one way or another.
>
> "huge" and "buggy" are just another way of spelling "expensive".
>
> If that means that i as owner can defeat the DRM _restrictions_, that's not
> that bad for me.
>
> I don't want to run a multi-user restricted-admin system. I want a desktop
> (just like 90% of the computer users out there), and for that I don't need
> that "good" DRM.

The problem is that what you can defeat a virus can probably defeat as well.

>
> If you talk about business to business services, that's an entirely 
different
> matter.

It's a myth that B2B services are any special. In the end the
businesses are run by people, and these people typically care much
less as it is not *their* business, they run it for somebody else.

>
>> In the later case the service might have too few resources to perform
>> as many transactions as you would wish, your use of the service might
>> degrade it for another user, or the other way around.
>
> How tight must the memory restriction be to have that issue?

It depends on your system. if you have 100x the resources you would
need for any task you will most likely not run into issues.

On the other hand, if your system resources are not abundant you will
certainly experience problems.

This is in fact how Linux sidesteps the issue. It has no resource
accounting and it is advised to just buy hardware beefy enough that
you do not experience problems.

>
>> So you ask the administrator to give more resources to the service.
>> Then it holds them even when you could use them for something else. If
>> they were allocated dynamically, which seems very questionable from a
>> security point of view, then another user could cause degradation of
>> other services for you by requesting many transactions and causing
>> allocation of lots of resources for sending IP datagrams.
>
> The system resources process could simply have per-user limits.

Then you are back to the state that the administrator reserves some
resources for the service.

>
>> You could certainly run your own IP stack but in the end you get to
>> DMA buffers of some PCI controller which have to be managed by the
>> system for security reasons and stored in memory while the
>> transmission is in progress.
>
> So the simple thing would be to just keep the minimal set which is necessary
> for security reasons under admin control using admin memory. The whole rest
> can be accessed by the user, and there's no need for granting applications 
use
> of memory I can no longer control.
>
> Developing a structure for taking away control from the user to solve this
> sounds a bit over the top for me.
>
> I'm sure there are deeper issues, but as I wrote I can't get into these.

I did not design a complete system that uses secure resource
accounting so I would not know if DRM is actually required for such
system. It can certainly simplify some parts of such design but then
again a workaround can be found for many cases.

>
>> > Which of those uses of DRM does Coyotos really make easy?
>>
>> DRM is about verifying with some degree of credibility that a piece of
>> information is not accessible to anyone else.
>>
>> That allows you to check with some degree of credibility that your
>> memory is not accessible to the administrator (although the
>> administrator should keep the capability to revoke your use of the
>> memory in case your account is terminated).
>
> This is a level of security I don't need.

I would think that most of the time I don't need it either. There were
some interesting use cases proposed but examining them showed flaws
that made the use of DRM impractical.

>
> In the end I have to trust the administrator, since he could just run a
> modified Coyotos which grants him hidden access to my memory but fakes being
> an unmodified Coyotos.
>
> So I only gain a false sens of security, which is worse than knowing
> beforehand that i have to trust my admin.
>
> Except if people plan to sell Coyotos in locked down devices where the admin
> can't change the system. But such a system would then go against my 
principles
> even more.
>
> Either it can be changed by the admin (who has or knows someone who has
> sufficient abilities), then any security against the admin is fake security.
> Or it can't be changed by the admin. Then it isn't allowed into my house,
> because it violates the principles of free software.

Yes, if the system is DRM capable then the core parts cannot be
changed - or if they are changed, the system no longer verifies as DRM
capable.

>
>> If you could the program would find out using some OS service and
>> would not allow you to download or store any protected content in the
>> first place.
>
> What keeps me from exchanging these OS routines with fake routines?
>
>> I have no idea how capabilities would be conveniently expressed when
>> running programs from the command line.
>> You can probably script the above and come with some syntax that is
>> easier to write.
>
> But then we're back at the level of adding convenience layers which is the
> same as offering a POSIX layer, just maybe not backwards compatible.

So allowing the user to run programs is a compatibility layer in itself?
Are you arguing that capability systems are not designed for that?
There must be some misunderstanding then.

>
>> Current mail programs do not have such feature but they could be
>> packaged so that a separate instance of the same program is used for
>> sending mail if you wished so.
>
> This all sounds like an awful lot of work which could better be spent in
> improving the applications for all systems.

If you make the application modular with isolated modules malfunction
in one module will typically not affect others - it will improve
reliability of the application on any syste.

>
> From what I see in Hurd development, making it possible to run any Linux
> application is done in the Hurd itself, so there's just one central place
> which needs changes.

Not really. You have to modify the applications to run on a new,
different system. This is called porting and/or packaging.

Unless you want the Linux binary emulation layer, of course.

>
> Changing every one of the I-don't-know-how-many complexer GUI applications 
to
> support capabilities sounds like a hell of a lot of more work.

Not really. You just change a few bits in the GUI toolkit they use and
most applications won't even notice. That's what the toolkits are for.
But you will have to overcome the differences between the two systems
in general, as you have to for any new system, including the Hurd.

>
>> > But many others don't. Should all of them be redesigned or abolished for
>> > the sake of using the capability system?
>>
>> They should be redesigned or abolished simply for the sake of
>> reliability and security, not for the sake of a capability system.
>
> With that the chances that I'd use such a system are damn low.

Why are you interested in the modular Hurd then? You can just use Linux.

The same principle of modularity and extensibility should apply to
applications too. They are part of the system.

If it does not they should be redesigned regardless of the system they run on.

>
> If there's a nice free program out there whoose development stopped in 2006, 
I
> want to be able to use it. Security means to me in that case, that I should 
be
> able to just grant the program the rigths it has with little effort.

How is that about security?

Security is about protecting something from something else.

The system should provide means to implement security easily and
should not force you to use it if you choose not to (although it
should come preconfigured for maximum security that can be achieved
practically).

However " I should be able to just grant the program the rigths it
has" makes no sense to me.

>
> It already uses UID and GID based access rights, so I need a POSIX layer.

Have you thought about porting the program?

Also perhaps the program could be even nicer if it was using
translators but sadly it does not :->

>
>> > Does that mean calling another process or just a thread with added
>> > capabilities?
>>
>> A thread as understood in, say, pthreads is not secure. It can access
>> the memory of other threads. You need the equivalent of a new process
>> running under a different account.
>
> Sounds like a paradigm shift again. People have been using threads for some
> years now - especially in GUIs, and rewriting all that code to inter-
process-
> communication will be a pain.

I do not say that threads should be abandoned. I just say that they
are not suitable for interfaces where security is required as they do
not have any protection whatsoever. Using external processes and
services is nothing new, it's widely used concept on POSIX systems.

Have you ever bothered to find out what is dcop?

>
>> > Where is the difference between using a capability layer and using the
>> > POSIX layer in the Hurd?
>>
>> The difference is that a system with fewer different layers and
>> incompatible concepts is easier to understand and manage.
>
> ...once you learned the new language.
>
> Before that it just isn't usable at all. And people are resistant to
> completely new things.
>
> So to get many people to use your system, you'll need to wrap it up into a
> layer they know, and we're back at POSIX or something similar but 
nonstandard.

Still you go from three layers to achieve the goal (secure and
reliable system) to only two layers with one being optional.

>
>> Many concepts in CS or math are equivalent but some problems are
>> easier to express and understand using different concepts.
>
> If I want a "pure" mathematician to use my program, it better look like his
> math, else he will use some other program which does.
>
> The same goes the other way round for programmers.
>

So if you want a secure system it's better to base the parts of system
responsible for security on concepts that allow expressing security
easily.

>> > My Bank account information is encrypted - he can't see that without
>> > giving my KDE wallet my password.
>>
>> It is decrypted at some point if you can view/use it.
>
> Here we are at a point I think: It is decrypted in my memory. If he got root
> access, he could now check my memory (the worst case), but I don't need to 
be
> able to sign away access rights to some other process to avoid that.
>
> it's enough to have a tree with lower and lower access rights, with the main
> process sitting at the top with access to all.

Yes, the only extensions required to the tree to support DRM are two:

 - putting one more process that sits above you and implements allows
spawning processes outside of the space accessible to you (there is
typically such process - some core parts of the system that run the
first program that can communicate with you in some comprehendible way
- the system core just needs not allow hiding stuff from you)
 - writing a driver for hardware cryptography device that allows
verifying the integrity of the system core (which is in practice hard
but the more secure and modular the system the easier it is to
identify and verify the core)

>
>> > $ hg update # Mercurial version tracking, update the working directory
>> >
>> > -> reads the manifest file, then reads the store files in question, then
>> > reads and writes to repository files. The subscription extension also
>> > offers the option of using an external config file which may be anywhere
>> > on the system.
>>
>> I don't know what is subscription extension.
>
> Sorry, my mistake - name mangling. I use it for email subscriptions...
>
> It's name is "NotifyExtension".

I do not see any particular problem with the extension unless it has
some surprising design inside.

It does not change that mercurial works with a repository, only sends
emails about a repository that is likely accessible anyway - I imagine
it being used for central public repositories.

If you wanted your repository kept secret then email is probably the
wrong medium anyway.

>
>> Under normal circumstances hg works on a repository (not sure how
>> exactly is each part called, there is the working dir, and the dir
>> with version tracking information) which is a bunch of related files
>> so you can just give hg access to the repository.
>>
>> I guess it would be also desirable to find a convenient way to pack
>> access to the upstream server with the repository.
>
>> > But the Hurd actually intends to make it possible to run KDE out of the
>> > box once development is there (that will be the point when I can start
>> > using teh Hurd as production system).
>>
>> Since when does the Hurd plan to implement a Linux binary
>> compatibility layer? This is big news to me.
>
> I run Gentoo, so I have about two binaries on my system: OpenOffice and
> Firefox :)
>
> The rest is built from source without needing my interaction, so that's what 
I
> mean with "out of the box".
>
> "emerge kde" or "apt-get kde" should suffice for getting it to run.

This is only possible because somebody already wrote patches build
scripts, and integration scripts for the applications in question.

This is what is packaging for. Many applications do not run flawlessly
even on Gento when you just configure, make and install them, and even
fewer do on the Hurd.

>
>> However. even if you compile KDE on the Hurd and fix up all the
>> deficiencies in the Hurd and KDE that make them incompatible the KDE
>> would perform the same as it does on Linux. To make use of the
>> translators you would have to further modify it. Sure, you can step
>> outside of KDE and set up the translators in a terminal but that is
>> not unlike running KDE inside a POSIX compatibility layer on a system
>> that is otherwise design around capabilities.
>
> So you have the POSIX compatibility layer again.

Yes, but there is a difference about basing your system on POSIX and
providing enough of POSIX interfaces to make porting POSIX software
easy. Like there is a difference between ReactOS and WineLib.

>
>> > A capability system doesn't do that.
>>
>> How so?
>
> My lovely little program which is no longer managed won't work, since it 
uses
> group permissions, for example.
>

You see, there comes a point when a program becomes obsolete. Either
you can patch enough compatibility into the program and the system to
work together or you just write a new one.

You cannot expect that every time you install a new system every
program you used to like on your previous system will work
effortlessly again.

>> I know there are things that are interesting about the Hurd. But there
>> are also interesting things about the BSDs and people aren't rushing
>> for them either. This is because there is inherent difficulty in
>> running less mainstream system - at least with current system design,
>> and it is not outweighted by the advantages the system provides in
>> most cases.
>
> But pure capability systems are even less mainstream, and they are even 
harder
> to put to normal use, and ease of running DRM badness on them won't bring 
many
> free programmers either.

Technically you can express capabilities in terms of POSIX security
model, it's only hard.

You need:
 - a secure POSIX system (sic)
 - ACLs of reasonably unlimited length
 - a service that allows you to create "subusers" - new users that
have subset of the permissions you already have
Here you need the unlimited ACLs as you will create a new user for
every new set of capabilities you want to express, and record the set
of capabilities as permissions for that user with ACLs.
Also there needs to be some bookkeeping so that it's obvious which
subuser is whose.

This is a "user" concept stretched very far, and it's basically what
the lightweight virtualization and partial isolation tools on top of
Hurd try to offer. So it would be much cleaner to just strip the
middle POSIX uid layer where it is not needed.

However, DRM (or as much DRM as the media companies want) requires
only very special sets of permissions so creating a DRM service is
much easier than that.

So there goes the DRM badness.

As for capabilities being alien - only people who are really
interested in something obscure or different look at the Hurd, and it
won't change if you make it more like Linux. It is necessary to have
enough tools bundled to explore the system and later to support daily
tasks like reading mail or browsing the web preinstalled, not to
conform to what current system look like.

The translator concept is not very easy for people to understand, or
was not before there was FUSE. It is mainstream now.
Either way it does not change how you run your email client unless the
client is explicitly written to make use of translators, and so it
would be with capabilities.

>[...]
> Evaluation:
> * What is the cost of running a Hurd in the niche?
> * What is the benefit of running a Hurd in the niche?

 - using capabilities as the basic security concept (as opposed to
POSIX uids) will make expressing security concepts easier and more
practical
 - it will make porting of applications that make non-trivial use of
POSIX security harder

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Freitag 28 November 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>, "Neal H. Walfield" 
<neal@walfield.org>

@Neal: Can you give some insight into resource accounting? Does a system have 
to support DRM to allow for fair resource accounting? 

Am Donnerstag 27 November 2008 22:56:51 schrieb Michal Suchanek:
> Yes, it is possible to write emails. And if there were currently a
> buffer overflow in libpng and I sent you specially crafted email with
> a PNG image I might manage to break into your account, and since it's
> a single user system breaking into your account is all that matters -
> there is nothing useful beyond your account.

There's the account of my wife :) 

And more importantly: There is the root account which can install a libpng 
version without the weakness. 

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. 

And this doesn't mean, that the knife is too blunt to cut anything. It just 
means that it can't cut solid steel. And I don't need a knife which can cut 
solid steel, when I only need to cut hard bread. 

The cost for getting a knife which can cut solid steel in the way you propose 
is paid in a probable loss of freedom for future generations (quite similar to 
a steel cutting knife which runs on petrol), and for me that cost is too high 
a price to pay. 

> Currently you can. There is no effective DRM to date as far as I know,
> at least for desktop systems.

Windows Vista? 

> > I don't want to run a multi-user restricted-admin system. I want a
> > desktop (just like 90% of the computer users out there), and for that I
> > don't need that "good" DRM.
>
> The problem is that what you can defeat a virus can probably defeat as
> well.

The virus doesn't have root access (unless I grow very dumb), so it doesn't 
have the means I have. 

> > How tight must the memory restriction be to have that issue?
>
> It depends on your system. if you have 100x the resources you would
> need for any task you will most likely not run into issues.

Please restrict that "100x" to "100x the memory you need for any system task". 

Yes, I have far more than 100x the memory I need for the DMA buffer of my 
drive, and I also have far more than 100x the memory I need for IP datagrams 
and similar. 

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. 

> > The system resources process could simply have per-user limits.
>
> Then you are back to the state that the administrator reserves some
> resources for the service.

Not for a single service, but for all services of the user. That's the 
difference here. 

The admin gives the user a pool of system memory he can use for any task. 

> > I'm sure there are deeper issues, but as I wrote I can't get into these.
>
> I did not design a complete system that uses secure resource
> accounting so I would not know if DRM is actually required for such
> system. It can certainly simplify some parts of such design but then
> again a workaround can be found for many cases.

Then, let's give Neal Walfield a chance to speak up. He added resource 
accounting to Viengoos, so he might have the needed knowledge. 

(I don't say "secure" here - what I need is fair resource accounting, not 
secure resource accounting). 

> > This is a level of security I don't need.
>
> I would think that most of the time I don't need it either. There were
> some interesting use cases proposed but examining them showed flaws
> that made the use of DRM impractical.

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). 

> > Either it can be changed by the admin (who has or knows someone who has
> > sufficient abilities), then any security against the admin is fake
> > security. Or it can't be changed by the admin. Then it isn't allowed into
> > my house, because it violates the principles of free software.
>
> Yes, if the system is DRM capable then the core parts cannot be
> changed - or if they are changed, the system no longer verifies as DRM
> capable.

Verifies by whom? 

Where is the component I cannot change? 

And why should I allow such a component in my free system? 

> > But then we're back at the level of adding convenience layers which is
> > the same as offering a POSIX layer, just maybe not backwards compatible.
>
> So allowing the user to run programs is a compatibility layer in itself?
> Are you arguing that capability systems are not designed for that?
> There must be some misunderstanding then.

No. I say that adding a layer which facilitates specifying capabilities is 
quite similar to adding a POSIX layer. 

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. 

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? 

> If you make the application modular with isolated modules malfunction
> in one module will typically not affect others - it will improve
> reliability of the application on any syste.

Modularity and using seperate processes is still a difference. 

> > Changing every one of the I-don't-know-how-many complexer GUI
> > applications to support capabilities sounds like a hell of a lot of more
> > work.
>
> Not really. You just change a few bits in the GUI toolkit they use and
> most applications won't even notice. That's what the toolkits are for.
> But you will have to overcome the differences between the two systems
> in general, as you have to for any new system, including the Hurd.

The toolkit should do a good deal of the work, that's right. 

But I do think that porting to the Hurd should prove quite a bit easier than 
porting to a system without POSIX layer. 

> >> They should be redesigned or abolished simply for the sake of
> >> reliability and security, not for the sake of a capability system.
> >
> > With that the chances that I'd use such a system are damn low.
>
> Why are you interested in the modular Hurd then? You can just use Linux.

Because it offers other benefits than only security. 

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). 

> > If there's a nice free program out there whoose development stopped in
> > 2006, I want to be able to use it. Security means to me in that case,
> > that I should be able to just grant the program the rigths it has with
> > little effort.
>
> How is that about security?

For me the Hurd is about using a system, not only about security. 

> The system should provide means to implement security easily and
> should not force you to use it if you choose not to (although it
> should come preconfigured for maximum security that can be achieved
> practically).
>
> However " I should be able to just grant the program the rigths it
> has" makes no sense to me.

Sorry if my english was flawed there. I meant "it should be easy to give the 
application the rights I want to give it". 

> > It already uses UID and GID based access rights, so I need a POSIX layer.
>
> Have you thought about porting the program?
>
> Also perhaps the program could be even nicer if it was using
> translators but sadly it does not :->

Firstoff I want it to work without too much interaction from me. 

All the reworking sounds nice, but in the end I don't have the time for it - 
but I need the program for my task at hand. 

> > Sounds like a paradigm shift again. People have been using threads for
> > some years now - especially in GUIs, and rewriting all that code to
> > inter-process- communication will be a pain.
>
> I do not say that threads should be abandoned. I just say that they
> are not suitable for interfaces where security is required as they do
> not have any protection whatsoever. Using external processes and
> services is nothing new, it's widely used concept on POSIX systems.

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. 

> Have you ever bothered to find out what is dcop?

That's what is being replaced by dbus in KDE4 :)

> > So to get many people to use your system, you'll need to wrap it up into
> > a layer they know, and we're back at POSIX or something similar but
> > nonstandard.
>
> Still you go from three layers to achieve the goal (secure and
> reliable system) to only two layers with one being optional.

The third layer you name (a translator which can access the capabilities) is 
optional as well. 

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. 

> So if you want a secure system it's better to base the parts of system
> responsible for security on concepts that allow expressing security
> easily.

If I want a system for a security expert, that's the way to go, yes. 

But if I want a system for a programmer who already knows POSIX and wants to 
express secuirty concepts, I better give him a POSIX system. 

> > it's enough to have a tree with lower and lower access rights, with the
> > main process sitting at the top with access to all.
>
> Yes, the only extensions required to the tree to support DRM are two:
>
>  - putting one more process that sits above you and implements allows
> spawning processes outside of the space accessible to you (there is
> typically such process - some core parts of the system that run the
> first program that can communicate with you in some comprehendible way
> - the system core just needs not allow hiding stuff from you)

But there's someone who installed that part in the first place, and that's the 
same person from whom this addition takes rights away (root). 

So what keeps him from just modifying that first process to give him power 
again? 

>  - writing a driver for hardware cryptography device that allows
> verifying the integrity of the system core (which is in practice hard
> but the more secure and modular the system the easier it is to
> identify and verify the core)

Same as above. 

It would still be possible for applications to call the crypto-device directly 
via assembler, but then there's still the crypto device which most times 
belongs to the one who is root. 

The only way to archieve more security here is to use an unfree crypto device, 
and that's a road I don't want to go down. It means throwing away 
archievements we already have because we make our free system dependent on 
unfree stuff. 

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. 

> I do not see any particular problem with the extension unless it has
> some surprising design inside.

It can use a config file from anywhere on the system. So what capabilities do 
I assign to Mercurial? 

Restricting it to the repository directory will reduce the usefulness of the 
notify extension. 

> > "emerge kde" or "apt-get kde" should suffice for getting it to run.
>
> This is only possible because somebody already wrote patches build
> scripts, and integration scripts for the applications in question.
>
> This is what is packaging for. Many applications do not run flawlessly
> even on Gento when you just configure, make and install them, and even
> fewer do on the Hurd.

But for me it seems that the patching and porting would be far more work on a 
system without POSIX layer. 

> > So you have the POSIX compatibility layer again.
>
> Yes, but there is a difference about basing your system on POSIX and
> providing enough of POSIX interfaces to make porting POSIX software
> easy. Like there is a difference between ReactOS and WineLib.

The Hurd offers a POSIX layer, because the GNU tools use POSIX, and I want to 
use the GNU tools. 

> > My lovely little program which is no longer managed won't work, since it
> > uses group permissions, for example.
>
> You see, there comes a point when a program becomes obsolete. Either
> you can patch enough compatibility into the program and the system to
> work together or you just write a new one.

That's a no go when the program is nontrivial and my time is limited. 

> You cannot expect that every time you install a new system every
> program you used to like on your previous system will work
> effortlessly again.

But if I see two systems which offer _me_ the same advantages (I don't need 
effective DRM), I will choose the one to which I can more easily port my 
applications. 

> This is a "user" concept stretched very far, and it's basically what
> the lightweight virtualization and partial isolation tools on top of
> Hurd try to offer. So it would be much cleaner to just strip the
> middle POSIX uid layer where it is not needed.
>
> However, DRM (or as much DRM as the media companies want) requires
> only very special sets of permissions so creating a DRM service is
> much easier than that.
>
> So there goes the DRM badness.

But as you read: It won't go into the Hurd, and people will go to lengths to 
ensure that. 

> The translator concept is not very easy for people to understand, or
> was not before there was FUSE. It is mainstream now.
> Either way it does not change how you run your email client unless the
> client is explicitly written to make use of translators, and so it
> would be with capabilities.

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. 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Samstag 29 November 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Neal H. Walfield" <neal@walfield.org>

2008/11/28 Neal H. Walfield <neal@walfield.org>:
> At Fri, 28 Nov 2008 19:29:25 +0100,
> Arne Babenhauserheide wrote:
>>
>> Am Freitag 28 November 2008 17:33:43 schrieb Neal H. Walfield:
>> > At Fri, 28 Nov 2008 17:11:35 +0100,
>> >
>> > Arne Babenhauserheide wrote:
>> > > @Neal: Can you give some insight into resource accounting? Does a 
system
>> > > have to support DRM to allow for fair resource accounting?
>> >
>> > Why do you think this would be the case?
>> >
>> > What does resource accounting have to do with DRM?
>>
>> Michal said that Resource accounting might imply mechanisms which
>> automatically allow easy DRM, so I wanted to ask you about your experiences
>> with Viengoos.
>
> What you are discussing is how to simultaneously avoid denial of
> service attacks and destructive interference.  A satisfactory solution
> will likely require resource accounting, however, that is not the main
> issue.
>
> Consider a server that manages state on behalf of multiple clients.
> Either it can use its own memory or the user can supply any required
> resources.  If a user can revoke the memory at any time or change its
> content and the server is using it to maintain a linked list, then the
> user can influence how the server interacts with other clients.  The
> easy solution is to allow the server to somehow use resources that are
> accounted to the user, not accessible to it but are revocable by it.
>
> Now, the question is: is this DRM?  The answer is not clear.  We have
> assumed that clients are users.  However, clients are really programs
> and restricting progrmas as opposed to users does not seem to be a
> real issue to me.  Indeed, I want to restrict what programs can do.
>

No, this is not DRM by itself. It uses the same mechanism as DRM does
(because if the protection was not effective the memory could be
manipulated by another process, and if the protection is effective and
the server does not belong to the same user this is what effective DRM
requires).

The step that turns this setup into DRM is certifying that system can
do effective DRM and installing drivers for a TPM device that verifies
the integrity of the system.

Obviously you could use the DRM without the certification but then it
could be defeated by changing the system components that implement the
security.

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Samstag 29 November 2008
Von: "Neal H. Walfield" <neal@walfield.org>
An: "Michal Suchanek" <hramrach@centrum.cz>

At Sat, 29 Nov 2008 03:00:14 +0100,
Michal Suchanek wrote:
> > Now, the question is: is this DRM?  The answer is not clear.  We have
> > assumed that clients are users.  However, clients are really programs
> > and restricting progrmas as opposed to users does not seem to be a
> > real issue to me.  Indeed, I want to restrict what programs can do.
> >
> 
> No, this is not DRM by itself. It uses the same mechanism as DRM does
> (because if the protection was not effective the memory could be
> manipulated by another process, and if the protection is effective and
> the server does not belong to the same user this is what effective DRM
> requires).

I agree.

> The step that turns this setup into DRM is certifying that system can
> do effective DRM and installing drivers for a TPM device that verifies
> the integrity of the system.

I think there are weaker protection mechanisms that effectively fall
under DRM, which we need to be weary of.  In short, if the owner of
the system is unable to control the system then it smells DRMesque to
me.

Neal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Sonntag 30 November 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

2008/11/29 Arne Babenhauserheide <arne_bab@web.de>:
> Am Freitag 28 November 2008 20:36:16 schrieb Neal H. Walfield:
[...]
>> Now, the question is: is this DRM?  The answer is not clear.  We have
>> assumed that clients are users.  However, clients are really programs
>> and restricting progrmas as opposed to users does not seem to be a
>> real issue to me.  Indeed, I want to restrict what programs can do.
>
> Can you give the users higher control over the memory than the programs? For
> example making a user a manager for the memory (or similar)?

The communication of the user with the sytem is also facilitated by a
program - the user shell. So any restriction that might apply to
programs might also apply to the user shell.

Perhaps in the default configuration the system would be shipped with
a single 'root' shell but later more restricted user shells might be
spawned which do not have access to all of the system (which is
advisable - in general you do not want everybody who can use a
computer to have root access).

The default distribution can then be modified to create a distribution
where even the 'root' shell has some restrictions - that's unavoidable
on any system that allows restricting programs. This is in my view the
only difference between systems implementing DRM and not implementing
DRM. However, without special (but quite common) cryptographic
hardware the DRM can be bypassed by examining the system when it is
not running.

Thanks

Michal



Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Mittwoch 03 Dezember 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Am Sonntag 30 November 2008 21:08:43 schrieb Michal Suchanek:
> The default distribution can then be modified to create a distribution
> where even the 'root' shell has some restrictions - that's unavoidable
> on any system that allows restricting programs. 

If the system is GPLv3, the root shell can't be made unfixable (a restricted 
root shell is broken), since the user *must* have a way to change the system, 
else the distributor violates the GPL. 

The only way to avoid that is putting the nonchangeable parts on ROM (and 
making them completely unupdateable), but even then the rest of the system 
must not depend on them for operation. 

But it is possible to design the system in such a way that it is very hard to 
get a root shell with full access, for example by not implementing an option 
to grant access to some other process but the memory server. 

But whoever does so sacrifices debugging options for the sake of having DRM 
against root, so if there's no unrestricted root shell in a system, that 
systems creator definitely showed a DRM supporters ugly face.  


@Neal: Do you see other ways to avoid enabling effective DRM while allowing 
users to restrict programs? Or is there an error in the reasoning I didn't 
spot? 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Donnerstag 04 Dezember 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Hi Neal, Hi Michal, 

Can I forward our discussion as one mail to bug-hurd, so all participants are 
up to date again? 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Freitag 05 Dezember 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

2008/12/3 Arne Babenhauserheide <arne_bab@web.de>:
> Am Sonntag 30 November 2008 21:08:43 schrieb Michal Suchanek:
>> The default distribution can then be modified to create a distribution
>> where even the 'root' shell has some restrictions - that's unavoidable
>> on any system that allows restricting programs.
>
> If the system is GPLv3, the root shell can't be made unfixable (a restricted
> root shell is broken), since the user *must* have a way to change the 
system,
> else the distributor violates the GPL.
>

Look at TiVO - they do not forbid modifying the software but forbid
running the modified software.

However, the DRM verification is something different - they allow you
to run whatever you want on your computer (so far) but they want to
allow accessing protected content only when your system verifies as
known DRM enforcing one (although the verification is technically
unfeasible so far).

I am not sure if GPLv3 or anything else protects you from that.

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Freitag 05 Dezember 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

2008/11/28 Arne Babenhauserheide <arne_bab@web.de>:
> @Neal: Can you give some insight into resource accounting? Does a system 
have
> to support DRM to allow for fair resource accounting?
>
> Am Donnerstag 27 November 2008 22:56:51 schrieb Michal Suchanek:
>> Yes, it is possible to write emails. And if there were currently a
>> buffer overflow in libpng and I sent you specially crafted email with
>> a PNG image I might manage to break into your account, and since it's
>> a single user system breaking into your account is all that matters -
>> there is nothing useful beyond your account.
>
> There's the account of my wife :)
>
> 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.

>
> 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.

>
> And this doesn't mean, that the knife is too blunt to cut anything. It just
> means that it can't cut solid steel. And I don't need a knife which can cut
> solid steel, when I only need to cut hard bread.
>
> The cost for getting a knife which can cut solid steel in the way you 
propose
> is paid in a probable loss of freedom for future generations (quite similar 
to
> a steel cutting knife which runs on petrol), and for me that cost is too 
high
> a price to pay.
>
>> 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 don't want to run a multi-user restricted-admin system. I want a
>> > desktop (just like 90% of the computer users out there), and for that I
>> > don't need that "good" DRM.
>>
>> The problem is that what you can defeat a virus can probably defeat as
>> well.
>
> 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.

>
>> > How tight must the memory restriction be to have that issue?
>>
>> It depends on your system. if you have 100x the resources you would
>> need for any task you will most likely not run into issues.
>
> Please restrict that "100x" to "100x the memory you need for any system 
task".
>
> Yes, I have far more than 100x the memory I need for the DMA buffer of my
> drive, and I also have far more than 100x the memory I need for IP datagrams
> and similar.
>
> 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.

>
>> > The system resources process could simply have per-user limits.
>>
>> Then you are back to the state that the administrator reserves some
>> resources for the service.
>
> Not for a single service, but for all services of the user. That's the
> difference here.
>
> 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.

>
>> > I'm sure there are deeper issues, but as I wrote I can't get into these.
>>
>> I did not design a complete system that uses secure resource
>> accounting so I would not know if DRM is actually required for such
>> system. It can certainly simplify some parts of such design but then
>> again a workaround can be found for many cases.
>
> Then, let's give Neal Walfield a chance to speak up. He added resource
> accounting to Viengoos, so he might have the needed knowledge.
>
> (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.

>
>> > This is a level of security I don't need.
>>
>> I would think that most of the time I don't need it either. There were
>> some interesting use cases proposed but examining them showed flaws
>> that made the use of DRM impractical.
>
> 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.

Security is useful for protecting your system from outside threats and
software malfunction. It can be also used to implement DRM which is
useless until somebody shows an example where it adds any value but
that does not discard the utility of security.

>
>> > Either it can be changed by the admin (who has or knows someone who has
>> > sufficient abilities), then any security against the admin is fake
>> > security. Or it can't be changed by the admin. Then it isn't allowed into
>> > my house, because it violates the principles of free software.
>>
>> Yes, if the system is DRM capable then the core parts cannot be
>> changed - or if they are changed, the system no longer verifies as DRM
>> capable.
>
> Verifies by whom?
>
> Where is the component I cannot change?
>
> 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.

Otherwise this component is the part of the system that does enforce
some security, and a third party that the DRM content provider trusts
certifies that a particular version (as recognized by a checksum which
is created by a cryptographic hardware) indeed enforces the security.

>
>> > But then we're back at the level of adding convenience layers which is
>> > the same as offering a POSIX layer, just maybe not backwards compatible.
>>
>> So allowing the user to run programs is a compatibility layer in itself?
>> Are you arguing that capability systems are not designed for that?
>> There must be some misunderstanding then.
>
> No. I say that adding a layer which facilitates specifying capabilities is
> quite similar to adding a POSIX layer.
>
> 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?

>
> 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.

>
>> If you make the application modular with isolated modules malfunction
>> in one module will typically not affect others - it will improve
>> reliability of the application on any syste.
>
> Modularity and using seperate processes is still a difference.

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

>
>> > Changing every one of the I-don't-know-how-many complexer GUI
>> > applications to support capabilities sounds like a hell of a lot of more
>> > work.
>>
>> Not really. You just change a few bits in the GUI toolkit they use and
>> most applications won't even notice. That's what the toolkits are for.
>> But you will have to overcome the differences between the two systems
>> in general, as you have to for any new system, including the Hurd.
>
> The toolkit should do a good deal of the work, that's right.
>
> 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.

>
>> >> They should be redesigned or abolished simply for the sake of
>> >> reliability and security, not for the sake of a capability system.
>> >
>> > With that the chances that I'd use such a system are damn low.
>>
>> Why are you interested in the modular Hurd then? You can just use Linux.
>
> Because it offers other benefits than only security.
>
> 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.

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

>
>> > If there's a nice free program out there whoose development stopped in
>> > 2006, I want to be able to use it. Security means to me in that case,
>> > that I should be able to just grant the program the rigths it has with
>> > little effort.
>>
>> How is that about security?
>
> For me the Hurd is about using a system, not only about security.

For me usable system should have customizable user interface, support
some available and usable hardware, and have some
security/multitasking features that actually allow running several
applications without much trouble.

GNU/Linux fails at the third requirement, the Hurd at the third and second.

Sure I also want a system that does not needlessly restrict the user
but there is not much problem with Linux in that area when used for
personal systems.

>
>> The system should provide means to implement security easily and
>> should not force you to use it if you choose not to (although it
>> should come preconfigured for maximum security that can be achieved
>> practically).
>>
>> However " I should be able to just grant the program the rigths it
>> has" makes no sense to me.
>
> Sorry if my english was flawed there. I meant "it should be easy to give the
> application the rights I want to give it".

if those rights are expressed as what the application can access then
you surely can do that on a capability system.

If those rights cannot be expressed like that then what rights the
application has?

>
>> > It already uses UID and GID based access rights, so I need a POSIX layer.
>>
>> Have you thought about porting the program?
>>
>> Also perhaps the program could be even nicer if it was using
>> translators but sadly it does not :->
>
> Firstoff I want it to work without too much interaction from me.
>
> All the reworking sounds nice, but in the end I don't have the time for it -
> but I need the program for my task at hand.

Then use a mainstream system with many applications readily available
like Windows or GNU/Linux.

>
>> > Sounds like a paradigm shift again. People have been using threads for
>> > some years now - especially in GUIs, and rewriting all that code to
>> > inter-process- communication will be a pain.
>>
>> I do not say that threads should be abandoned. I just say that they
>> are not suitable for interfaces where security is required as they do
>> not have any protection whatsoever. Using external processes and
>> services is nothing new, it's widely used concept on POSIX systems.
>
> 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.

>
>> Have you ever bothered to find out what is dcop?
>
> That's what is being replaced by dbus in KDE4 :)
>
>> > So to get many people to use your system, you'll need to wrap it up into
>> > a layer they know, and we're back at POSIX or something similar but
>> > nonstandard.
>>
>> Still you go from three layers to achieve the goal (secure and
>> reliable system) to only two layers with one being optional.
>
> The third layer you name (a translator which can access the capabilities) is
> optional as well.
>
> 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.

>
>> So if you want a secure system it's better to base the parts of system
>> responsible for security on concepts that allow expressing security
>> easily.
>
> If I want a system for a security expert, that's the way to go, yes.
>
> But if I want a system for a programmer who already knows POSIX and wants to
> express secuirty concepts, I better give him a POSIX system.

There are pretty much no viable security concepts in POSIX so you end
up with an insecure program most of the time.

>
>> > it's enough to have a tree with lower and lower access rights, with the
>> > main process sitting at the top with access to all.
>>
>> Yes, the only extensions required to the tree to support DRM are two:
>>
>>  - putting one more process that sits above you and implements allows
>> spawning processes outside of the space accessible to you (there is
>> typically such process - some core parts of the system that run the
>> first program that can communicate with you in some comprehendible way
>> - the system core just needs not allow hiding stuff from you)
>
> But there's someone who installed that part in the first place, and that's 
the
> same person from whom this addition takes rights away (root).
>
> 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.

>
>>  - writing a driver for hardware cryptography device that allows
>> verifying the integrity of the system core (which is in practice hard
>> but the more secure and modular the system the easier it is to
>> identify and verify the core)
>
> Same as above.
>
> It would still be possible for applications to call the crypto-device 
directly
> via assembler, but then there's still the crypto device which most times
> belongs to the one who is root.
>
> The only way to archieve more security here is to use an unfree crypto 
device,
> and that's a road I don't want to go down. It means throwing away
> archievements we already have because we make our free system dependent on
> unfree stuff.
>
> 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.

>
>> I do not see any particular problem with the extension unless it has
>> some surprising design inside.
>
> It can use a config file from anywhere on the system. So what capabilities 
do
> I assign to Mercurial?
>
> Restricting it to the repository directory will reduce the usefulness of the
> notify extension.
>
>> > "emerge kde" or "apt-get kde" should suffice for getting it to run.
>>
>> This is only possible because somebody already wrote patches build
>> scripts, and integration scripts for the applications in question.
>>
>> This is what is packaging for. Many applications do not run flawlessly
>> even on Gento when you just configure, make and install them, and even
>> fewer do on the Hurd.
>
> 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?

>
>> > So you have the POSIX compatibility layer again.
>>
>> Yes, but there is a difference about basing your system on POSIX and
>> providing enough of POSIX interfaces to make porting POSIX software
>> easy. Like there is a difference between ReactOS and WineLib.
>
> The Hurd offers a POSIX layer, because the GNU tools use POSIX, and I want 
to
> use the GNU tools.

Which GNU tools rely so much on POSIX?

>
>> > My lovely little program which is no longer managed won't work, since it
>> > uses group permissions, for example.
>>
>> You see, there comes a point when a program becomes obsolete. Either
>> you can patch enough compatibility into the program and the system to
>> work together or you just write a new one.
>
> That's a no go when the program is nontrivial and my time is limited.

Then the Hurd is probably not the system for you. Whatever kernel or
concept it will be based on much software will have to be ported and
patched to run on it.

>
>> You cannot expect that every time you install a new system every
>> program you used to like on your previous system will work
>> effortlessly again.
>
> But if I see two systems which offer _me_ the same advantages (I don't need
> effective DRM), I will choose the one to which I can more easily port my
> applications.
>
>> This is a "user" concept stretched very far, and it's basically what
>> the lightweight virtualization and partial isolation tools on top of
>> Hurd try to offer. So it would be much cleaner to just strip the
>> middle POSIX uid layer where it is not needed.
>>
>> However, DRM (or as much DRM as the media companies want) requires
>> only very special sets of permissions so creating a DRM service is
>> much easier than that.
>>
>> So there goes the DRM badness.
>
> But as you read: It won't go into the Hurd, and people will go to lengths to
> ensure that.
>
>> The translator concept is not very easy for people to understand, or
>> was not before there was FUSE. It is mainstream now.
>> Either way it does not change how you run your email client unless the
>> client is explicitly written to make use of translators, and so it
>> would be with capabilities.
>
> 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.

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Freitag 05 Dezember 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

2008/12/4 Arne Babenhauserheide <arne_bab@web.de>:
> Hi Neal, Hi Michal,
>
> Can I forward our discussion as one mail to bug-hurd, so all participants 
are
> up to date again?

Yes, I guess it fell off the list when I sent one message twice (once
to you and once to the list, because the list does not use any list
headers my mail software would understand, and I hit the wrong button
accidentally) and you replied to the message that did not go to the
list.

Thanks

Michal

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Sonntag 07 Dezember 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Am Freitag 05 Dezember 2008 12:56:29 schrieb Michal Suchanek:
> Yes, I guess it fell off the list when I sent one message twice (once
> to you and once to the list, because the list does not use any list
> headers my mail software would understand, and I hit the wrong button
> accidentally) and you replied to the message that did not go to the
> list.

I didn't know if you wanted to go offlist, after Olaf said the discussion had 
already been done before, but as the mail only went to me I assumed so. 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Sonntag 07 Dezember 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Am Freitag 05 Dezember 2008 12:56:29 schrieb Michal Suchanek:
> Yes, I guess it fell off the list when I sent one message twice (once
> to you and once to the list, because the list does not use any list
> headers my mail software would understand, and I hit the wrong button
> accidentally) and you replied to the message that did not go to the
> list.

I didn't know if you wanted to go offlist, after Olaf said the discussion had 
already been done before, but as the mail only went to me I assumed so. 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Sonntag 07 Dezember 2008
Von: Arne Babenhauserheide <arne_bab@web.de>
An: "Michal Suchanek" <hramrach@centrum.cz>

Am Freitag 05 Dezember 2008 12:56:29 schrieb Michal Suchanek:
> Yes, I guess it fell off the list when I sent one message twice (once
> to you and once to the list, because the list does not use any list
> headers my mail software would understand, and I hit the wrong button
> accidentally) and you replied to the message that did not go to the
> list.

I didn't know if you wanted to go offlist, after Olaf said the discussion had 
already been done before, but as the mail only went to me I assumed so. 

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

-------------------------------------------------------
----------  Weitergeleitete Nachricht  ----------

Betreff: Re: Niches for the Hurd: evaluation method; was: DRM musings, 
capabilities and stuff
Datum: Dienstag 09 Dezember 2008
Von: "Michal Suchanek" <hramrach@centrum.cz>
An: "Arne Babenhauserheide" <arne_bab@web.de>

On 08/12/2008, Arne Babenhauserheide <arne_bab@web.de> wrote:
> Am Montag 08 Dezember 2008 13:37:14 schrieb Michal Suchanek:
>
> > However, a non-free application may require certain known version of
>  > the otherwise free system (and driver for hardware cryptographic
>  > device) to run or allow access to protected content.
>
>
> This would mean that I as user could use the system only for a subset of the
>  things the verifier could use it (even though that usage may only be added
>  later), so that would be a severe usage restriction and very likely a GPLv3
>  violation if the driver were part of the GPLv3 system.

The driver itself does not restrict the use of the system, it only
identifies what system you are running (among other things).

It probably would not be part of a GNU system but I do not see how
adding it would violate any license.

Thanks

Michal

-------------------------------------------------------
-- 
-- 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.