Re: Upstream first policy

Re: Upstream first policy

[James Morris]

On Thu, 4 Mar 2010, Linus Torvalds wrote:

> On Thu, 4 Mar 2010, Kyle McMartin wrote:
>> 
>> I recommend you don't look at Ubuntu, we might have a lot of extra
>> crud[2] in the kernel if you do. :) (Actually, shockingly less than I
>> thought, just apparmor, aufs, ndiswrapper are the obvious ones.)
> 
> Ok, so ndiswrapper falls under the "yeah, no" heading.
> 
> But apparmor was supposed to be on the "yeah, we'll merge it" path, I 
> talked to somebody about it not _that_ long ago. Some of the security 
> people object, but they object for all the wrong reasons and I really do 
> think that since it's getting used, we really should merge it.

The AppArmor developer has been posting patches for review -- there's 
nothing stopping the code being merged except for the need to address 
purely technical issues raised by reviewers, which is ongoing.

See: http://thread.gmane.org/gmane.linux.kernel.lsm/10443

> Although there was _some_ noise about Ubuntu trying to move away from 
> it.. But that may have been more of the whole FUD thing from the people 
> who for some unfathomable reason think that inodes are more important 
> than pathnames.

Hey, thanks for another random unfounded personal attack, it's really 
appreciated.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, James Morris wrote:
>
> > it.. But that may have been more of the whole FUD thing from the people 
> > who for some unfathomable reason think that inodes are more important 
> > than pathnames.
> 
> Hey, thanks for another random unfounded personal attack, it's really 
> appreciated.

It really isn't personal, you know. I don't even remember _who_ it was 
that thought that pathname-based security was fundamentally wrong and was 
bad-mouthing apparmor all they could. My point was just that there's a lot 
of mindless "my way or the highway" in some security circles, and apparmor 
really has been ridiculed.

It's not _that_ long ago that some group was trying to get rid of LSM just 
because "selinux is the only valid model".

		Linus

Re: Upstream first policy

[Linus Torvalds]

On Sun, 7 Mar 2010, Linus Torvalds wrote:
>
> 	My point was just that there's a lot of mindless "my way or the 
> highway" in some security circles, and apparmor really has been 
> ridiculed.

.. and perhaps more fundamentally, the deeper point was that that in no 
way stops the "upstream first" policy. Some Ubuntu people who wanted to 
get it merged were in fact worried that it might.

			Linus

Re: Upstream first policy

[Ingo Molnar]

* James Morris <jmorris@namei.org> wrote:

> On Thu, 4 Mar 2010, Linus Torvalds wrote:
> 
> > On Thu, 4 Mar 2010, Kyle McMartin wrote:
> >> 
> >> I recommend you don't look at Ubuntu, we might have a lot of extra
> >> crud[2] in the kernel if you do. :) (Actually, shockingly less than I
> >> thought, just apparmor, aufs, ndiswrapper are the obvious ones.)
> > 
> > Ok, so ndiswrapper falls under the "yeah, no" heading.
> > 
> > But apparmor was supposed to be on the "yeah, we'll merge it" path, I 
> > talked to somebody about it not _that_ long ago. Some of the security 
> > people object, but they object for all the wrong reasons and I really do 
> > think that since it's getting used, we really should merge it.
> 
> The AppArmor developer has been posting patches for review -- there's 
> nothing stopping the code being merged except for the need to address 
> purely technical issues raised by reviewers, which is ongoing.
> 
> See: http://thread.gmane.org/gmane.linux.kernel.lsm/10443
> 
> > Although there was _some_ noise about Ubuntu trying to move away from it.. 
> > But that may have been more of the whole FUD thing from the people who for 
> > some unfathomable reason think that inodes are more important than 
> > pathnames.
> 
> Hey, thanks for another random unfounded personal attack, it's really 
> appreciated.

Btw., now that we are a few reasonable months after the last big security 
flamewar it would be nice to see a rehash or fair summary of the pathname 
versus labels arguments. That particular issue does seem to be largely 
technical and thus we ought to be able to judge it one way or another.

IMO the main challenge in Linux security is to find and engage the right 
critical mass of developers to truly increase the security of 'Linux' as a 
whole in the long run.

That means, almost by definition, that we do not start by trying to create an 
'as secure as possible' system in the short run. Increased security is the 
_end goal_, not the means. I.e. we need a technology _process_ that results in 
more secure Linux systems.

( Trying to create an 'as secure as possible' system will almost certainly 
  backfire, as it results in _fewer_ developers/users caring. )

In that sense it appears to me that it's pretty much a universal truth that 
'pathnames' are a far more fitting abstraction to any 'human based security 
process' on Linux than 'labels'. (It does not matter at all that security 
research suggest that the most secure systems are label based and that there 
are some hard problems with pathname based approaches such as hardlinks, 
--bind mounts, etc.)

So here i see somewhat of a conceptual failure of SELinux that would be nice 
to see fixed: inherent hostility against pathname based approaches, just 
because they are technically less secure.

To me the relabeling performance problem and the fact that selinux labels are 
physically attached to the objects themselves is a potentially bigger 
'security problem' than the racy nature (and aliasing/ambiguity problems) of 
VFS pathname based security is.

In other words: i see selinux's main failure in that it somewhat blindly aims 
for a security model that it sees as the technicaly most secure, while not 
being intellectually open to the fact that we very likely _cannot know in 
advance_ which of the models will make Linux more secure in the long run.

For example did you consider the possibility that the road towards a label 
based approach may as well be most practical _over_ a proxy step that used 
pathname based security? (i.e. once there's a critical mass of pathname based 
security policies, and there's distros/developers/users who maintain it, a 
much smaller step towards labels could be attempted - possibly automated to a 
certain degree.)

We cannot know how it will end up looking like in a few years because security 
is one of the few areas where computer technology mixes so strongly with 
psychology, and a secure system of this human scale was never attempted 
before. Prior security research is thus largely irrelevant. This also means 
that paradoxically, this intellectual inflexibility over the basic security 
model may as well make Linux less secure.

Also, why was/(is?) AppArmor considered as a 'hostile competitor' - instead of 
treating it more like a natural ally: another mechanism that allows us to 
_expand_ the total pool of per app security policies (and, more importantly, 
the pool of developers who care about those policies)?

Thanks,

	Ingo

Re: Upstream first policy

[Alan Cox]

> In that sense it appears to me that it's pretty much a universal truth that 
> 'pathnames' are a far more fitting abstraction to any 'human based security 

Ingo - just about all the serious security work disagrees with you.
Pathnames are references to objects and keep changing. What matters is
the object itself. This is also how Unix has always worked

Imagine if chmod applied to the path not the inode ?

> Also, why was/(is?) AppArmor considered as a 'hostile competitor' 

I don't believe it was. It was perceived as a technical failure, and then
the file system people shredded the bits the security folks didn't.

There are certain things path name bases security works quite nicely for,
primarily systems that have no concept of links. It's why it works
ok-ish for httpd but for the general case nobody has ever really made it
work properly.

Alan

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Alan Cox wrote:
> 
> Ingo - just about all the serious security work disagrees with you.
> Pathnames are references to objects and keep changing. What matters is
> the object itself. This is also how Unix has always worked

The thing is, that's simply not the whole truth. It's _part_ of the truth, 
but there very much are pathname-based security in Unix too, including 
very much traditionally.

Things like "/etc/passwd" really are about the _pathname_, not the inode. 
It really is the _path_ that is special, because that is fundamentally the 
thing you trust.

You can try to turn that into a content-based security issue by claiming 
that it's about the "content of the '/etc' directory", and that is (along 
with other tricks) obviously how a a content-based security model has to 
work.

But it's not actually _true_ in any deeper sense. You're really just 
trying to enforce a pathname-based model using a inode/content based 
security hammer.

So that's an example of "if all you have is a hammer, everything looks 
like a nail" issue. If all you have is a content/inode-based security, you 
have to turn path-names into "directory inode" issues, and it's doable, 
but it's really like trying to convince everybody that screws do not exist 
because all you have is a hammer.

And when you base your security on inodes, you _do_ have problems with 
things like /etc. Exactly because there are many different paths in that 
directory, and they actually have _different_ security issues. A program 
that is supposed to be able to edit/replace /etc/hosts is _not_ supposed 
to be able to edit/replace /etc/passwd.

Notice how it's really fundamentally about the pathname? When you create a 
new file and overwrite /etc/passwd with that file, the security rules 
really do _not_ come from your newly created inode, they come from the 
fact that you made the path "/etc/passwd" point to that inode.

And again - you can emulate this with the inode-based thing. Your hammer 
does work, but it doesn't really invalidate the fact that the path really 
is what is most fundamental in that case, because the pathname is 
fundamentally the shared piece of information that different processes 
work with.

You end up making up new ideas to handle this: it's why traditional BSD 
UNIX security has the setgid and sticky bit on directories, and it's also 
obviously why selinux ends up having special rules for "link" and "rename" 
etc - exactly so that you can emulate security that is really 
fundamentally about the pathname.

In other words: it really _does_ make more sense to say "this process has 
rights to overwrite the path '/etc/passwd'" than it does to try to label 
the file. The _fundamental_ rule is about the pathname. The labeling comes 
about BECAUSE YOU USED A HAMMER FOR A SCREW.

I really don't understand why some people are unable to admit this fact. 

				Linus

Re: Upstream first policy

[Al Viro]

On Mon, Mar 08, 2010 at 10:08:31AM -0800, Linus Torvalds wrote:

> In other words: it really _does_ make more sense to say "this process has 
> rights to overwrite the path '/etc/passwd'" than it does to try to label 
> the file. The _fundamental_ rule is about the pathname. The labeling comes 
> about BECAUSE YOU USED A HAMMER FOR A SCREW.
> 
> I really don't understand why some people are unable to admit this fact. 

Because you don't have to use that pathname to modify the bits returned
by read() after open() on that pathname?

I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply
doesn't match how the pathname resolution is defined on Unix...

Re: Upstream first policy

[Al Viro]

On Mon, Mar 08, 2010 at 06:45:21PM +0000, Al Viro wrote:
> On Mon, Mar 08, 2010 at 10:08:31AM -0800, Linus Torvalds wrote:
> 
> > In other words: it really _does_ make more sense to say "this process has 
> > rights to overwrite the path '/etc/passwd'" than it does to try to label 
> > the file. The _fundamental_ rule is about the pathname. The labeling comes 
> > about BECAUSE YOU USED A HAMMER FOR A SCREW.
> > 
> > I really don't understand why some people are unable to admit this fact. 
> 
> Because you don't have to use that pathname to modify the bits returned
> by read() after open() on that pathname?
> 
> I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply
> doesn't match how the pathname resolution is defined on Unix...

PS: at that point the *only* things I care about wrt "security" junk are
	* it shouldn't create new assertions to keep for VFS and fs code
	* it shouldn't break the normal Unix permissions for boxen that
sanely have all that crap disabled
	* it shouldn't make one vomit just from RTFS
	* it shouldn't create obvious rootholes when enabled
	* it shouldn't add overhead from hell
	* it shouldn't try to hide the violations of the conditions above

My opinion of the "security community" is worse than yours, BTW.  You have
decided that to let their stuff in; IMO it had been a mistake from the very
beginning, but that's your tree.

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Al Viro wrote:
> > 
> > I really don't understand why some people are unable to admit this fact. 
> 
> Because you don't have to use that pathname to modify the bits returned
> by read() after open() on that pathname?

The thing is, I don't think it's an "either or".

Sure, there is content security. Nobody disputes that. The security 
decision about how to open a file is about the contents of the file.

So I'm not suggesting we _replace_ content-based security with 
pathname-based security. I'm just saying that pathnames actually do matter 
for security, and that they are an independent issue.

> I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply
> doesn't match how the pathname resolution is defined on Unix...

Again, I'm not claiming that we should change how "open" works and has 
always worked. I don't even understand why you have that crazy "either or" 
mentality to begin with. Why?

It's not "either pathname or inode". I'm saying _both_ make sense. 

In some situations, the name itself really is what is fundamentally 
special about the file.

		Linus

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Linus Torvalds wrote:
> 
> Sure, there is content security. Nobody disputes that. The security 
> decision about how to open a file is about the contents of the file.

Btw, I would also say that content security is generally the _common_ 
case. So I'm not at all saying that the traditional unix model or the 
selinux model is in any way "wrong". Not at all.

It's just that I certainly understand why some people think AppArmor is 
more "intuitive". And I think it's directly related to the fact that 
sometimes the pathname-based approach is the one that more directly 
reflects the particular issue (and people are often happy with the 
traditional UNIX semantics for plain inode-based security, so again, it's 
not like AppArmor _replaces_ inode-based security, it _extends_ on it).

			Linus

Re: Upstream first policy

[Alan Cox]

> always worked. I don't even understand why you have that crazy "either or" 
> mentality to begin with. Why?
> 
> It's not "either pathname or inode". I'm saying _both_ make sense. 

SELinux uses both. Things like "I put a file in my public_html directory"
are a good example.

Its object based in the sense that the origin of the data might matter
(eg 'no app which opens the credit card db creates a file httpd can send')

Its path based in the sense that public_html has a path based meaning by
convention understood by httpd. Copy a jpeg into your public_html and it
will be labelled up for http access under the Fedora shipped rule sets.

Alan

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Alan Cox wrote:
>
> Its path based in the sense that public_html has a path based meaning by
> convention understood by httpd. Copy a jpeg into your public_html and it
> will be labelled up for http access under the Fedora shipped rule sets.

Umm. That was my point all along: you can basically "emulate" pathname 
based decisions by labeling things. But it's not always the most direct 
approach, and some people clearly do find AppArmor (or Tomoyo, which I 
think is also largely based on pathnames) to be more "intuitive".

So I don't understand it when people then complain about a mechanism that 
base their decisions fundamentally on the pathname. It's not like AppArmor 
got rid of the traditional unix inode-based protections and replaced them 
(like your silly DEC10 example).

But whatever. The fact is, Ubuntu uses it. We'll merge it.

				Linus

Re: Upstream first policy

[Kyle McMartin]

On Mon, Mar 08, 2010 at 11:32:16AM -0800, Linus Torvalds wrote:
> But whatever. The fact is, Ubuntu uses it. We'll merge it.
> 

I'd be ever so thrilled if you'd merge utrace in that case...

cheers, Kyle

Re: Upstream first policy

[Chris Adams]

Once upon a time, Alan Cox  <alan@lxorguk.ukuu.org.uk> said:
>Its path based in the sense that public_html has a path based meaning by
>convention understood by httpd. Copy a jpeg into your public_html and it
>will be labelled up for http access under the Fedora shipped rule sets.

I'm pretty sure the "copy into a directory" only gets the correct label
by inheritance from the parent directory.

"mkdir public_html" only gets the correct label by running the
restorecond daemon, which is really kind of a hack.  You have a
user-space daemon that watches for creation of specific things with
inotify, and resets their label when a match is found.  It doesn't scale
up to many rules, certainly not the full SELinux list.

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Upstream first policy

[Al Viro]

On Mon, Mar 08, 2010 at 10:59:11AM -0800, Linus Torvalds wrote:

> > I'm not fond of selinux, to put it mildly, but "pathname-based" stuff simply
> > doesn't match how the pathname resolution is defined on Unix...
> 
> Again, I'm not claiming that we should change how "open" works and has 
> always worked. I don't even understand why you have that crazy "either or" 
> mentality to begin with. Why?
> 
> It's not "either pathname or inode". I'm saying _both_ make sense. 
> 
> In some situations, the name itself really is what is fundamentally 
> special about the file.

And mapping from names to files is a function of contents of many objects.
You need to protect that contents on all objects involved *anyway*.  Which
leaves what for "protecting by pathname"?

I'm not saying that it's either or.  I am saying that it's been oversold
to hell and back, BTW, but that's a separate story.  And I'm very sceptical
about separate protection of different directory entries, which is *all*
that is left for pathname-based stuff, AFAICS.

Re: Upstream first policy

[Luca Barbieri]

I think the point is actually that, ideally, content-based security is
for _reads_, while path-based security is for _writes_:

For example, in the /etc/shadow case:
1. Unprivileged users must not be able to know the _content_ of the
file (or of any copy of it)
2. It doesn't matter at all if anyone modifies a private copy of the
file (with the same content, but not the same path)
3. Unprivileged users must not change the data the /etc/shadow _path_
is associated with
4. It doesn't matter at all if anyone reads a file that happens to be
at /etc/shadow while not containing shadow passwords (with the same
path, but different content)

So I think we should enforce label/inode-based content security on
reads, but we should enforce path/dentry-based security on writes.

In particular, doing a write on a file, and moving a file to that same
path ought to have exactly the same security checks, since the
user-visible effect is the same.

The unix model is broken regarding this, since one will depend on the
write permissions on the file inode, and the other on the directory.
Ideally, both should depend on the write permissions of the _dentry_
(there would need to be a concept of default dentry permissions for a
directory).

The only thing that breaks this are hard links, since they allow to
change the data associated with multiple unknown dentries in a single
operation. However, completely disallowing writes to inodes with
multiple links solves the problem, and shouldn't require fundamental
(or any) userspace changes (of course, this is to be done by the
security module, not by the generic vfs).

Re: Upstream first policy

[Al Viro]

On Tue, Mar 09, 2010 at 02:18:13AM +0100, Luca Barbieri wrote:
> 4. It doesn't matter at all if anyone reads a file that happens to be
> at /etc/shadow while not containing shadow passwords (with the same
> path, but different content)

What the hell are you smoking?

Re: Upstream first policy

[Luca Barbieri]

>> 4. It doesn't matter at all if anyone reads a file that happens to be
>> at /etc/shadow while not containing shadow passwords (with the same
>> path, but different content)
>
> What the hell are you smoking?

I mean, what is interesting for security of reading is the fact that
the file contains shadow passwords (and thus is labeled as "secret" or
with a specific label), not that it is at /etc/shadow.

The same security check would need to apply to an administrator's
backup copy of /etc/shadow, but would not need to apply in the
hypotetical case that /etc/shadow did not contain shadow passwords,
but, say, was empty or contained a pointer to a network server to use.

This is to illustrate the point, not something expected to happen; it
also represents the ideal security model, not necessarily any concrete
one.

So what really is interesting for reads is what the content is (in
practice, what the content label is), not the path.

For writes, it is exactly the opposite: you don't care about writing
to a private copy, but you don't want to let a random file be put on a
system path.
For instance, if I copy /etc/passwd somewhere else, the result should
have the same content label (since it is identical), but I should now
be able to write to it since the path allows me to.

Re: Upstream first policy

[Al Viro]

On Tue, Mar 09, 2010 at 02:51:55AM +0100, Luca Barbieri wrote:
> >> 4. It doesn't matter at all if anyone reads a file that happens to be
> >> at /etc/shadow while not containing shadow passwords (with the same
> >> path, but different content)
> >
> > What the hell are you smoking?
> 
> I mean, what is interesting for security of reading is the fact that
> the file contains shadow passwords (and thus is labeled as "secret" or
> with a specific label), not that it is at /etc/shadow.

<sarcasm>
Yeah, especially when it's read by sshd.  Who cares, indeed?  So it's got
a passwordless root, that's even better, right?  Nobody will see your
real root password that way...
</sarcasm>

Re: Upstream first policy

[Luca Barbieri]

> <sarcasm>
> Yeah, especially when it's read by sshd.  Who cares, indeed?  So it's got
> a passwordless root, that's even better, right?  Nobody will see your
> real root password that way...
> </sarcasm>

Not sure what you mean exactly.
You won't have a passwordless root if you don't allow anyone to modify
the file at /etc/shadow, or change that dentry by deleting a file
there or putting an arbitrary file there (with creat, rename or link).
This is conceptually a path-based security check.

It is also separate from the problem of not giving anyone knowledge of
the root password or hash of it, which a conceptually content-based
security check on reads.

Re: Upstream first policy

[Alan Cox]

> Things like "/etc/passwd" really are about the _pathname_, not the inode. 
> It really is the _path_ that is special, because that is fundamentally the 
> thing you trust.

Why can I trust the path ?

> But it's not actually _true_ in any deeper sense. You're really just 
> trying to enforce a pathname-based model using a inode/content based 
> security hammer.

Quite untrue. I've actually *used* path based security systems (DEC10
ACLs) and for almost every case its brain-dead.

Imagine a world where this happened

	echo "hello" > fred
	chmod 666 fred
	ls -l fred
	fred rw-rw-rw-
	mv fred bill
	ls -l bill
	bill rw-------

week later
	vi fred
	ls -l fred
	fred rw-rw-rw-

Your password file is a special case

> And when you base your security on inodes, you _do_ have problems with 
> things like /etc. Exactly because there are many different paths in that 
> directory, and they actually have _different_ security issues. A program 
> that is supposed to be able to edit/replace /etc/hosts is _not_ supposed 
> to be able to edit/replace /etc/passwd.

In a secure system I don't just care if its called /etc/passwd. I care
that whoever made changes to it was trusted to do so and furthermore that
the suid binary, the libraries it relies upon and the other points of
trust that matter. Real security is *not* a file permissions system its a
trust model including things like integrity validation.

Another reason this is true is how passwd is updated - the tool creates
a new file of some name like passwd.tmp and does processing into that,
then renames it over the top. If I break passwd.tmp then you'll trust the
result "because it's called passwd", while a system that keeps
permissions and labels attached to the object will not because someone
tampered with the object that became passwd.

> Notice how it's really fundamentally about the pathname? When you create a 
> new file and overwrite /etc/passwd with that file, the security rules 
> really do _not_ come from your newly created inode, they come from the 
> fact that you made the path "/etc/passwd" point to that inode.

No - they come from whatever created or modified the file. It doesn't
matter what an object is called if I need to know whether the data in it
is honest.

> You end up making up new ideas to handle this: it's why traditional BSD 
> UNIX security has the setgid and sticky bit on directories, and it's also 
> obviously why selinux ends up having special rules for "link" and "rename" 
> etc - exactly so that you can emulate security that is really 
> fundamentally about the pathname.

The directory bits move with the directory - they are object
permissions to retrofit delete permission (a gap in the original
Unix design) and a very crude inheritance hack.

They are not about paths. If you mv a file into a directory with these
properties they don't magically inherit the properties.

> the file. The _fundamental_ rule is about the pathname. The labeling comes 
> about BECAUSE YOU USED A HAMMER FOR A SCREW.
> 
> I really don't understand why some people are unable to admit this fact. 

Perhaps because
- They understand what they are talking about and have studied the
  research
- They've got a grasp of the mathematical/logical models that this is all
  based upon
- They know the difference between access control lists and security
  models
- They aren't so arrogant as to assume that using the capslock key
  overrides fifty years of research

??

Alan

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Alan Cox wrote:
>
> Quite untrue. I've actually *used* path based security systems (DEC10
> ACLs) and for almost every case its brain-dead.
> 
> Imagine a world where this happened

Alan, stop right there.

You're making the same silly and incorrect mistake that Al did.

Namely thinking that you have to have just one or the other.

When you say "your /etc/passwd example is a special case", you are 
admitting that there are two different cases, but then after that,  you 
still don't see the whole point I'm trying to make.

Let me try again:

  THERE ARE DIFFERENT CASES

That's the point. Just admit that, and then let the calm of "Ooh, there 
are different kinds of circumstances that may want different kinds of 
rules" permeate you.

My whole (and only) argument is against the "only one way is correct" 
mentality.

			Linus

Re: Upstream first policy

[Alan Cox]

> That's the point. Just admit that, and then let the calm of "Ooh, there 
> are different kinds of circumstances that may want different kinds of 
> rules" permeate you.

man restorecond

I don't think the SELinux folks would or could deny that case existed...

Alan

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Alan Cox wrote:
> 
> man restorecond

I know. I also sometimes sit through minutes of "let's relabel the system, 
because you've booted a kernel without selinux support".

			Linus

Re: Upstream first policy

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 8 Mar 2010, Alan Cox wrote:
> > 
> > man restorecond
> 
> I know. I also sometimes sit through minutes of "let's relabel the system, 
> because you've booted a kernel without selinux support".

I've had selinux relabeling wait times of an hour or two too, on a 
sufficiently large filesystem.

I think this hurts security far more than anything else, because it causes 
people to actually _turn off the whole thing_ - so we will have less and less 
security in the end.

( To use the obligatory fire door analogy: we should prefer a one inch thick 
  fire door that opens and closes fully automated to a five inches thick fire 
  door that people keep always-open with a chair. )

	Ingo

Re: Upstream first policy

[Dave Airlie]

On Tue, Mar 9, 2010 at 5:29 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Mon, 8 Mar 2010, Alan Cox wrote:
>> >
>> > man restorecond
>>
>> I know. I also sometimes sit through minutes of "let's relabel the system,
>> because you've booted a kernel without selinux support".
>
> I've had selinux relabeling wait times of an hour or two too, on a
> sufficiently large filesystem.
>
> I think this hurts security far more than anything else, because it causes
> people to actually _turn off the whole thing_ - so we will have less and less
> security in the end.
>
> ( To use the obligatory fire door analogy: we should prefer a one inch thick
>  fire door that opens and closes fully automated to a five inches thick fire
>  door that people keep always-open with a chair. )

selinux relabels are the new fsck.

maybe we need selinux3 or chunk-selinux.

Dave.

Re: Upstream first policy

[Ulrich Drepper]

On Tue, Mar 9, 2010 at 00:46, Dave Airlie <airlied@gmail.com> wrote:
> selinux relabels are the new fsck.
>
> maybe we need selinux3 or chunk-selinux.

Once the fanotify stuff is in (or however it'll be called) the new
relabel process could temporarily install itself to intercept all
filesystem operations and fix up files on demand while going along
it's normal operation in the background.  No reason to stall the
system completely.

If this is the biggest complaint then you should be supportive of the approach.

Re: Upstream first policy

[Eric W. Biederman]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 8 Mar 2010, Alan Cox wrote:
>>
>> Quite untrue. I've actually *used* path based security systems (DEC10
>> ACLs) and for almost every case its brain-dead.
>> 
>> Imagine a world where this happened
>
> Alan, stop right there.
>
> You're making the same silly and incorrect mistake that Al did.
>
> Namely thinking that you have to have just one or the other.
>
> When you say "your /etc/passwd example is a special case", you are 
> admitting that there are two different cases, but then after that,  you 
> still don't see the whole point I'm trying to make.
>
> Let me try again:
>
>   THERE ARE DIFFERENT CASES
>
> That's the point. Just admit that, and then let the calm of "Ooh, there 
> are different kinds of circumstances that may want different kinds of 
> rules" permeate you.
>
> My whole (and only) argument is against the "only one way is correct" 
> mentality.


Reading through all of this it occurred to me there is a case where
path names are fundamentally important shows up for me all of the
time.  If pathnames were not fundamentally important we could apply
a patch like the one below and allow unprivileged users to unshare
the mount namespace and mount filesystems wherever.  There is nothing
fundamental about those operations that require root privileges except
that you are manipulating the pathnames of objects.

Unfortunately if we did that suid executables would become impossible
because they couldn't trust anything to start with.

Even little things like /lib64/ld-linux-x86-64.so are very special things
that you can't let just anyone change.

Eric


diff --git a/fs/namespace.c b/fs/namespace.c
index d69c06f..85ba785 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1650,10 +1650,6 @@ static int do_new_mount(struct path *path, char *type, int flags,
 	if (!type)
 		return -EINVAL;
 
-	/* we need capabilities... */
-	if (!capable(CAP_SYS_ADMIN))
-		return -EPERM;
-
 	lock_kernel();
 	mnt = do_kern_mount(type, flags, name, data);
 	unlock_kernel();
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 1e8cda0..00fd7c5 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -180,9 +180,6 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
 			       CLONE_NEWNET | CLONE_NEWPID)))
 		return 0;
 
-	if (!capable(CAP_SYS_ADMIN))
-		return -EPERM;
-
 	*new_nsp = create_new_namespaces(unshare_flags, current,
 				new_fs ? new_fs : current->fs);
 	if (IS_ERR(*new_nsp)) {

Re: Upstream first policy

[Eric Paris]

On Mon, Mar 8, 2010 at 6:02 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Mon, 8 Mar 2010, Alan Cox wrote:
>>>
>>> Quite untrue. I've actually *used* path based security systems (DEC10
>>> ACLs) and for almost every case its brain-dead.
>>>
>>> Imagine a world where this happened
>>
>> Alan, stop right there.
>>
>> You're making the same silly and incorrect mistake that Al did.
>>
>> Namely thinking that you have to have just one or the other.
>>
>> When you say "your /etc/passwd example is a special case", you are
>> admitting that there are two different cases, but then after that,  you
>> still don't see the whole point I'm trying to make.
>>
>> Let me try again:
>>
>>   THERE ARE DIFFERENT CASES
>>
>> That's the point. Just admit that, and then let the calm of "Ooh, there
>> are different kinds of circumstances that may want different kinds of
>> rules" permeate you.
>>
>> My whole (and only) argument is against the "only one way is correct"
>> mentality.
>
>
> Reading through all of this it occurred to me there is a case where
> path names are fundamentally important shows up for me all of the
> time.  If pathnames were not fundamentally important we could apply
> a patch like the one below and allow unprivileged users to unshare
> the mount namespace and mount filesystems wherever.  There is nothing
> fundamental about those operations that require root privileges except
> that you are manipulating the pathnames of objects.
>
> Unfortunately if we did that suid executables would become impossible
> because they couldn't trust anything to start with.

You do realize that with content based security systems the pathnames
aren't important and you could implement your example patch?  Sure a
user could mount something on /lib and put their own files there, but
since that user couldn't get them labelled correctly the suid app
would not be able to use them and would fail.  Users would have new
and interesting way to break their computers!  I thank you for your
vote for content based security systems instead of pathname systems
and look forward to your future contributions to either that body of
knowledge or the bridging of the gap between the two *smile*

-Eric

Re: Upstream first policy

[Florian Mickler]

On Mon, 8 Mar 2010 18:18:21 -0500
Eric Paris <eparis@parisplace.org> wrote:


> You do realize that with content based security systems the pathnames
> aren't important and you could implement your example patch?  Sure a
> user could mount something on /lib and put their own files there, but
> since that user couldn't get them labelled correctly the suid app
> would not be able to use them and would fail.  Users would have new
> and interesting way to break their computers!  

but isn't that why a pathname based protect of /lib would be better? so
that users couldn't break their system? 

>I thank you for your
> vote for content based security systems instead of pathname systems
> and look forward to your future contributions to either that body of
> knowledge or the bridging of the gap between the two *smile*
> 
> -Eric

i interpret it not this way. but i'm an amateur securita :)

cheers,
Flo

Re: Upstream first policy

[Alan Cox]

> time.  If pathnames were not fundamentally important we could apply
> a patch like the one below and allow unprivileged users to unshare
> the mount namespace and mount filesystems wherever.  There is nothing
> fundamental about those operations that require root privileges except
> that you are manipulating the pathnames of objects.

And in a purely SELinux enviromnment your patch would work out because
you could use labels to control this stuff.
 

> -	if (!capable(CAP_SYS_ADMIN))
> -		return -EPERM;
> -

It does raise the question about whether you can do it if you had a
namespace property of "ignore suidness". I'm not sure thats enough
however.

Re: Upstream first policy

[Eric W. Biederman]

Weird.  Somehow I only got a copy of this from lkml.

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> time.  If pathnames were not fundamentally important we could apply
>> a patch like the one below and allow unprivileged users to unshare
>> the mount namespace and mount filesystems wherever.  There is nothing
>> fundamental about those operations that require root privileges except
>> that you are manipulating the pathnames of objects.
>
> And in a purely SELinux enviromnment your patch would work out because
> you could use labels to control this stuff.
>  
>
>> -	if (!capable(CAP_SYS_ADMIN))
>> -		return -EPERM;
>> -
>
> It does raise the question about whether you can do it if you had a
> namespace property of "ignore suidness". I'm not sure thats enough
> however.

The long term plan is to change that to.

	if (nscapable(mnt_ns->user_ns, CAP_SYS_ADMIN))
		return -EPERM.

That is.
- Create a new user/credential namespace (ultimately an unprivileged operation).
- Have the root user of the new user namespace create a new mount namespace.
- Over that new mount namespace the root user of the new user namespace
  has full control.

It is a little convoluted but it maintains backwards compatibility.  Unfortunately
there is still a long ways to go before we get there.

Eric

Re: Upstream first policy

[Ulrich Drepper]

On Mon, Mar 8, 2010 at 10:08, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Notice how it's really fundamentally about the pathname? When you create a
> new file and overwrite /etc/passwd with that file, the security rules
> really do _not_ come from your newly created inode, they come from the
> fact that you made the path "/etc/passwd" point to that inode.

This is not a fundamental problem.  It's rather a detail of the
current policies and legacy apps.

I think I would like to see /etc/passwd to also get a file type like
/etc/shadow.  This is I think today not done because of the work
involved and the perceived lower severity because passwords are in
/etc/shadow.

So let's talk about /etc/shadow.  If somehow the file is removed and
somebody creates a new file that file won't automatically get the
right label.  This means that code reading the file then could be
prevented from doing this with appropriate policy rules.  Here the
filename is not sufficient for access.  You also need the label and
that you won't get without subverting the system.  With filename based
mechanisms this isn't the case: once the file is compromised the
attack succeeded.

Yes, the current situation isn't optimal.  We have to make the
policies more complicated and we have to get rid of restorecond (at
least for most cases).  But there is no fundamental problem with
labels while filename-based mechanisms provide no security
improvement.

Re: Upstream first policy

[Eric Paris]

On Mon, Mar 8, 2010 at 5:12 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 10:08, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> Notice how it's really fundamentally about the pathname? When you create a
>> new file and overwrite /etc/passwd with that file, the security rules
>> really do _not_ come from your newly created inode, they come from the
>> fact that you made the path "/etc/passwd" point to that inode.
>
> This is not a fundamental problem.  It's rather a detail of the
> current policies and legacy apps.
>
> I think I would like to see /etc/passwd to also get a file type like
> /etc/shadow.  This is I think today not done because of the work
> involved and the perceived lower severity because passwords are in
> /etc/shadow.
>
> So let's talk about /etc/shadow.  If somehow the file is removed and
> somebody creates a new file that file won't automatically get the
> right label.  This means that code reading the file then could be
> prevented from doing this with appropriate policy rules.  Here the
> filename is not sufficient for access.  You also need the label and
> that you won't get without subverting the system.  With filename based
> mechanisms this isn't the case: once the file is compromised the
> attack succeeded.
>
> Yes, the current situation isn't optimal.  We have to make the
> policies more complicated and we have to get rid of restorecond (at
> least for most cases).  But there is no fundamental problem with
> labels while filename-based mechanisms provide no security
> improvement.

At the moment the default label of a new file is created based on the
label of the creating process and the label of the parent directory.
It's certainly not impossible that a third factor could be added 'the
last component of the pathname of the new inode' to the decision
matrix.  Doing so would eliminate the need for restorecond in most (or
maybe all) situations while maintaining the useful security principles
of label based enforcement.  It actually has been suggested and
implemented, but as I recall we were told it violated some VFS rules
to pass the information we passed where we passed it and it was
abandoned.

*tongue in cheek* if TOMOYO and AppArmour can do thing which the VFS
maintainer say is wrong and unacceptable merely by sending them to the
security maintainer instead I guess SELinux can do that as well!

answering a different post in the same email: I accept "THERE ARE
DIFFERENT CASES."  You go on to say "So I'm not suggesting we
_replace_ content-based security with pathname-based security. I'm
just saying that pathnames actually do matter for security, and that
they are an independent issue."  But what you are suggesting is
EXACTLY that our users should _replace_ content-based security with
pathname-based security when they have to boot with security=TOMOYO
instead of security=SMACK.  Rather than finding a flexible framework,
finding problems or inadequacies in that framework, and solving those
problems you instead force our users to have to choose between LSMs
which are either A) secueable but non-intuitive or B) not securable
but known to be 'easier'.

I think the inode based security view as a hammer might not be all
that bad.  It works really well on nails (you know the truely hard
well researched security questions) and it can beat screws into a
piece of wood as well (although sometimes the wood cracks).  Calling
pathname based security a screwdriver fits too, it can put the screws
in but we know there are a lot of nails out there which it can't ever
deal with.

Personally I think we should all get together and agree on a framework
and fix the framework to meet all of the needs and look like a swiss
army hammer driver drill thing rather than having 4 options, none of
which meet all the needs, and then forcing our uneducated users to
choose between them.  But, hey, we all know that isn't going to happen
so I'll just go back to happy go lucky dream land where Linus is not
running around naked with a chain saw.

-Eric

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Eric Paris wrote:
>
> answering a different post in the same email: I accept "THERE ARE
> DIFFERENT CASES."  You go on to say "So I'm not suggesting we
> _replace_ content-based security with pathname-based security. I'm
> just saying that pathnames actually do matter for security, and that
> they are an independent issue."  But what you are suggesting is
> EXACTLY that our users should _replace_ content-based security with
> pathname-based security when they have to boot with security=TOMOYO
> instead of security=SMACK.

No.

Because we already _have_ content-based security. The traditional UNIX 
model is all about "labeling", ie the inode-based security.

The fact that the extended security is then using something else in Tomoyo 
or AppArmor doesn't remove the traditional security model.

Again, your whole email is just "assuming" that selinux is the thing to 
be. No logic to your post at all. If you are using a AppArmor-based thing, 
you're not "switching" from SELinux to AppArmor. You're just using it.

Get it? The Ubuntu people seem to be happy with AppArmor. Deal with it. 
SELinux isn't the end-all and be-all of everything.

			Linus

Re: Upstream first policy

[Rik van Riel]

On 03/08/2010 01:08 PM, Linus Torvalds wrote:

> Things like "/etc/passwd" really are about the _pathname_, not the inode.
> It really is the _path_ that is special, because that is fundamentally the
> thing you trust.

On the other hand, '/etc/shadow' has the opposite constraint,
where the system will not trust most of the applications with
the data from that file.

Using label security to protect the contents makes sense there.

Your example appears to be about "can the application trust
the data?", while the label based security solves "can the
application be trusted with the data?"

These are two different things.

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Rik van Riel wrote:
> 
> On the other hand, '/etc/shadow' has the opposite constraint,
> where the system will not trust most of the applications with
> the data from that file.

Umm. No.

/etc/shadow is in no way at all different from /etc/passwd. Both of them 
have pathname-based security issues. The fact that both of them _also_ 
have content-based security issues is an independent issue that I just 
assumed everybody would take for granted.

Clearly I assumed too much.

So I was assuming that everybody realized that the normal inode-based UNIX 
security obviously means that you can only open /etc/passwd read-only as 
any normal user (and not open /etc/shadow at all: but that is in _no_ way 
different from /etc/passwd).

That's an example of non-pathname-based security, where you actually mark 
the content itself restricted some way. It's very naturally done with 
labels on the inode itself. It's what UNIX has _always_ done

Nobody has ever suggested removing that. That would be crazy.

But that thing is _independent_ from the other totally unrelated issue, 
namely the fact that "/etc/passwd" is a special name in the namespace. In 
other words, there is "content security", but then there is also 
"namespace security". 

Of course, you can make /etc unwritable, and that is indeed the 
traditional UNIX model of handling namespace security: by just 
implementing it as "content security" of the directory.

The sgid and sticky bits can be used to further try to make it more 
fine-grained (exactly becuase it is _not_ sufficient to say "you can't 
read or write this directory" on a whole-directory basis), and obviously 
SELinux has extensions of its own too.

Can you really not see the difference between security of naming thigns 
certain things (like "/etc/passwd") - pathname based issues - and the 
separate security of limiting access to any named device - actual markings 
on the inode itself?

				Linus

Re: Upstream first policy

[Rik van Riel]

On 03/08/2010 06:37 PM, Linus Torvalds wrote:

> That's an example of non-pathname-based security, where you actually mark
> the content itself restricted some way. It's very naturally done with
> labels on the inode itself. It's what UNIX has _always_ done
>
> Nobody has ever suggested removing that. That would be crazy.

It is quite clear that the content based security
protects the content from being manipulated by
processes that should not be able to do so.

However, what is unclear to me is ...

> But that thing is _independent_ from the other totally unrelated issue,
> namely the fact that "/etc/passwd" is a special name in the namespace. In
> other words, there is "content security", but then there is also
> "namespace security".

... what exactly does the namespace security protect against?

What is the threat model that the namespace security protects
against, which is not protected by the content based security?

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Rik van Riel wrote:
> 
> > But that thing is _independent_ from the other totally unrelated issue,
> > namely the fact that "/etc/passwd" is a special name in the namespace. In
> > other words, there is "content security", but then there is also
> > "namespace security".
> 
> ... what exactly does the namespace security protect against?
> 
> What is the threat model that the namespace security protects
> against, which is not protected by the content based security?

Umm? Seriously? 

What is _any_ security all about? You try to limit the opportunity for 
damage, accidental or not.

So let's take a trivial example. Let's say that you are root, and you edit 
/etc/shadow by hand. I've done it, you've probably done it, it's not 
rocket science. Now, you do it using any random editor, and most likely 
it's going to write the new file into a temp-file, and then rename that 
temp-file over the old file (perhaps creating a backup of the old file 
depending on editor and settings).

Now, think about what that implies for a moment. Especially consider the 
case that there were ACL's ("inode-based security") on the old /etc/passwd 
or /etc/shadow file that got moved away as a backup. What happened to 
those ACL's when you edited the file using a random editor?

Now, do you see what the difference between pathname-based and inode-based 
security is? Do you realize how if anybody wants to track accesses to 
/etc/shadow, they are not going to be interested in the _old_ backup copy 
of /etc/shadow?

				Linus

Re: Upstream first policy

[Casey Schaufler]

Linus Torvalds wrote:
> On Mon, 8 Mar 2010, Rik van Riel wrote:
>   
>>> But that thing is _independent_ from the other totally unrelated issue,
>>> namely the fact that "/etc/passwd" is a special name in the namespace. In
>>> other words, there is "content security", but then there is also
>>> "namespace security".
>>>       
>> ... what exactly does the namespace security protect against?
>>
>> What is the threat model that the namespace security protects
>> against, which is not protected by the content based security?
>>     
>
> Umm? Seriously? 
>
> What is _any_ security all about? You try to limit the opportunity for 
> damage, accidental or not.
>
> So let's take a trivial example. Let's say that you are root, and you edit 
> /etc/shadow by hand. I've done it, you've probably done it, it's not 
> rocket science. Now, you do it using any random editor, and most likely 
> it's going to write the new file into a temp-file, and then rename that 
> temp-file over the old file (perhaps creating a backup of the old file 
> depending on editor and settings).
>
> Now, think about what that implies for a moment. Especially consider the 
> case that there were ACL's ("inode-based security") on the old /etc/passwd 
> or /etc/shadow file that got moved away as a backup. What happened to 
> those ACL's when you edited the file using a random editor?
>
> Now, do you see what the difference between pathname-based and inode-based 
> security is? Do you realize how if anybody wants to track accesses to 
> /etc/shadow, they are not going to be interested in the _old_ backup copy 
> of /etc/shadow?
>
> 				Linus
>   

And if you really want to get down to brass tacks it wouldn't hurt
if either camp dusted off their faded copy of the DoD Orange Book
and read a few verses. The access control requirements are stated
in terms of objects but the audit requirements clearly want pathnames.
The security modelers were nuts to protect objects (inodes) but the
accountability fiends insisted on human readable identifiers (pathnames).
The early evaluations (a decade before Linux headed for the Common
Criteria) of Unix systems got bogged down for months at a time while
the needs of objects battled with the needs of accountability.

In the end neither side is right. There are useful things that you
can do with either, but as everyone and his demented gerbil has
pointed out, no one has the True Security Solution. Not even SELinux,
which violates some pretty fundamental security principles
(see: "small enough to be analyzed") in actual deployment. TOMOYO
violates "non-circumventable", just in case anyone thinks I'm
picking on someone. Heck, even Smack isn't perfect, although I will
leave it to others to autoclave that puppy.

Those of you who say we ought to come up with a single framework
that we can use to Do The Right Thing haven't been reading the code.
We have such a framework in the LSM. Sure it's mildly hackish, but
it has only been "open" to new modules for a couple years now, and
security development tends to be slow, with no hardware and blessed
little money behind it. How many file systems went into the VFS
before it got clean enough to talk about in public?

Further, we can polish the filesystem apple until the seeds show
and still never get anywhere near where the modern security issues
reside. Right, networking. Without a security model for that we can
debate how we want our eggs cracked and get just as close to a "real"
solution as we will with the inode/pathname debate.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>   

Re: Upstream first policy

[Linus Torvalds]

On Mon, 8 Mar 2010, Casey Schaufler wrote:
> 
> Those of you who say we ought to come up with a single framework
> that we can use to Do The Right Thing haven't been reading the code.
> We have such a framework in the LSM.

.. and people are also interested in using (and expanding) the 'notify' 
layer, probably because it is obviously designed for efficiently talking 
at a user-level program about the relevant accesses. Whether that is 
because they are just crazy ("malware detection") or whether it is an 
indication that the LSM layer and current security models are just not 
convenient enough, I dunno.

And whether all that has anything to do with "Do The Rigth Thing" is 
obviously very much unclear, but the interest is clearly there.

			Linus

Re: Upstream first policy

[Samir Bellabes]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 8 Mar 2010, Casey Schaufler wrote:
>> 
>> Those of you who say we ought to come up with a single framework
>> that we can use to Do The Right Thing haven't been reading the code.
>> We have such a framework in the LSM.
>
> .. and people are also interested in using (and expanding) the 'notify' 
> layer, probably because it is obviously designed for efficiently talking 
> at a user-level program about the relevant accesses. Whether that is 
> because they are just crazy ("malware detection") or whether it is an 
> indication that the LSM layer and current security models are just not 
> convenient enough, I dunno.

LSM layer gives enough to push the policy manager in userspace. Even
after that to a centralized server.

I worked on this, regarding networking. Next move should be to include
the LSM hooks regarding filesystem. [0]

I have concern about the way to do this, ie should we use the LSM layer
to do this, or should we put the features directly in the filesystem
stack or networking stack ?
At this point, it reminds me, ipchains (kernel 2.2) vs netfilter (kernel
2.4-2.6). At the beginning, with ipchains, filtering code was directly
in the network stack, and it wasn't the solution. So netfilter's hooks
was designed.

with LSM, we have a layer, and as sure as every one will come with his
own approach, I think we should keep code in stack (network, filesystem,
..) clean, and make the defering to userspace approach as a security
module. Then let the user/distro decided which features he want to use.

thanks,
sam

[0] http://lkml.org/lkml/2010/3/2/295

Re: Upstream first policy

[Al Viro]

On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote:

> Of course, you can make /etc unwritable, and that is indeed the 
> traditional UNIX model of handling namespace security: by just 
> implementing it as "content security" of the directory.
> 
> The sgid and sticky bits can be used to further try to make it more 
> fine-grained (exactly becuase it is _not_ sufficient to say "you can't 
> read or write this directory" on a whole-directory basis), and obviously 
> SELinux has extensions of its own too.

But that's not what the apparmor et.al. are doing.  If you want (and that's
not obviously a good thing) fine-grained access control for directory
entries, it would at least make some sense.  Prohibitively pricy, probably,
but that's a separate story.  But they are *NOT* protecting /foo/bar directory
entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
root.

And if you *do* protect each ancestor and try to keep granularity, you'll
end up with complexity from hell.

Re: Upstream first policy

[Al Viro]

On Tue, Mar 09, 2010 at 12:15:54AM +0000, Al Viro wrote:
> On Mon, Mar 08, 2010 at 03:37:38PM -0800, Linus Torvalds wrote:
> 
> > Of course, you can make /etc unwritable, and that is indeed the 
> > traditional UNIX model of handling namespace security: by just 
> > implementing it as "content security" of the directory.
> > 
> > The sgid and sticky bits can be used to further try to make it more 
> > fine-grained (exactly becuase it is _not_ sufficient to say "you can't 
> > read or write this directory" on a whole-directory basis), and obviously 
> > SELinux has extensions of its own too.
> 
> But that's not what the apparmor et.al. are doing.  If you want (and that's
> not obviously a good thing) fine-grained access control for directory
> entries, it would at least make some sense.  Prohibitively pricy, probably,
> but that's a separate story.  But they are *NOT* protecting /foo/bar directory
> entry when you want to protect /foo/bar/baz/barf; it doesn't go up towards
> root.
> 
> And if you *do* protect each ancestor and try to keep granularity, you'll
> end up with complexity from hell.

BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
sadistic), you'll see how seriously do they take pathname-based *anything*.
LSM hooks for namespace operations (you know, mount, umount) are lousy, but
they exist.  Not used by apparmor.

Re: Upstream first policy

[Linus Torvalds]

On Tue, 9 Mar 2010, Al Viro wrote:
> 
> BTW, if you actually look at apparmor (I'd suggest tomoyo, but I'm not _that_
> sadistic), you'll see how seriously do they take pathname-based *anything*.
> LSM hooks for namespace operations (you know, mount, umount) are lousy, but
> they exist.  Not used by apparmor.

That's a good point, btw, and shows one conceptual difference between 
content-based and pathname-based rules.

For example, if you want to log any changes to "/etc/passwd" (which is 
something pretty reasonable to do at least conceptually), what about doing 
a bind mount on top of that file?

That bind mount doesn't actually change the underlying file in any way. It 
doesn't even really _access_ it. From a content standpoint of the 
filesystem that contains the file, it's a total no-op.

But from an attack standpoint, you don't actually care, because nobody 
cares about the inode that used to be the contents of "/etc/passwd": all 
anybody _really_ cares about is "could somebody change what happens to the 
_name_ '/etc/passwd'".

But yeah, it's easy to overlook namespace changes when the obvious 
operations are read/write/unlink/rename. And I'm not at all surprised that 
people do.

			Linus

Re: Upstream first policy

[Al Viro]

On Mon, Mar 08, 2010 at 05:49:10PM -0800, Linus Torvalds wrote:

> That's a good point, btw, and shows one conceptual difference between 
> content-based and pathname-based rules.
> 
> For example, if you want to log any changes to "/etc/passwd" (which is 
> something pretty reasonable to do at least conceptually), what about doing 
> a bind mount on top of that file?

Doesn't have to be a binding over /etc/passwd, BTW.  /etc as a mountpoint will
serve just as well.

Re: Upstream first policy

[Linus Torvalds]

On Tue, 9 Mar 2010, Al Viro wrote:
> 
> Doesn't have to be a binding over /etc/passwd, BTW.  /etc as a mountpoint will
> serve just as well.

I agree. But I think more people are aware of a regular directory mount 
than about the ability to just mount a single file. So from a sneakyness 
standpoint, I like the "oh, btw, I just took over just the one file I care 
about" rather than trying to hide the whole directory.

Doesn't matter conceptually, though.

		Linus

Re: Upstream first policy

[Pavel Machek]

Hi!

> > Also, why was/(is?) AppArmor considered as a 'hostile competitor' 
> 
> I don't believe it was. It was perceived as a technical failure, and then
> the file system people shredded the bits the security folks didn't.

Unfortunately, in the meantime tomoyo was merged, which is basically
apparmor done wrong.

So I guess I owe an apology to apparmor people :-(.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Upstream first policy

[James Kosin]

On 3/8/2010 2:20 PM, Linus Torvalds wrote:
> 
> 
> 
> My whole (and only) argument is against the "only one way is correct" 
> mentality.
> 
> 			Linus
> --

Well said Linus.
If there where only one way to do this, it would have been done long
ago.  Fortunately, or unfortunately, there are about as many ways as
there are grains of sand.

James K.

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:36:55 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Yes Dave probably should have mentioned it in his pull request, but
> that doesn't seem to be a good reason not to pull imo...

And now I see Dave did mention this, so what gives.  Guidance please.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:

> On Thu, 4 Mar 2010 10:36:55 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Yes Dave probably should have mentioned it in his pull request, but
> > that doesn't seem to be a good reason not to pull imo...
> 
> And now I see Dave did mention this, so what gives.  Guidance please.

Yeah, it's in the first one. My bad. I didn't notice, because that one got 
cancelled for other reasons and never even tested.

That doesn't change the simple basic issue: how are people with Fedora-12 
going to test any kernel out now? And are there libdrm versions that can 
handle _both_ cases, so that people can bisect things? IOW, even if you 
have a new libdrm, will it then work with the _old_ kernel too?

Backwards compatibility is really important.

		Linus

Re: [git pull] drm request 3

[Jesse Barnes]

On Thu, 4 Mar 2010 10:51:20 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> > On Thu, 4 Mar 2010 10:36:55 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > Yes Dave probably should have mentioned it in his pull request, but
> > > that doesn't seem to be a good reason not to pull imo...
> > 
> > And now I see Dave did mention this, so what gives.  Guidance please.
> 
> Yeah, it's in the first one. My bad. I didn't notice, because that one got 
> cancelled for other reasons and never even tested.
> 
> That doesn't change the simple basic issue: how are people with Fedora-12 
> going to test any kernel out now? And are there libdrm versions that can 
> handle _both_ cases, so that people can bisect things? IOW, even if you 
> have a new libdrm, will it then work with the _old_ kernel too?
> 
> Backwards compatibility is really important.

Sure it is.  But OTOH this is very clearly a "use at your own risk"
driver.  Dave and the nouveau guys include the driver in Fedora to get
much needed test coverage, and make sure the latest bits in rawhide
work together.

The "use at your own risk" part is that you get to keep both pieces if
you try to mix and match kernels and userspace until the STAGING
moniker is removed.

If marking the driver as staging doesn't allow them to break ABI when
they need to, then it seems like they'll have no choice but to either
remove the driver from upstream and only submit it when the ABI is
stable, or fork the driver and submit a new one only when the ABI is
stable.  Neither seem particularly attractive.

Of course I'm implicitly trusting their motivation for breaking ABI in
this case, but that was very much a part of the merge discussion so
shouldn't come as a surprise to anyone.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [git pull] drm request 3

[Linus Torvalds]

On Thu, 4 Mar 2010, Jesse Barnes wrote:
> 
> If marking the driver as staging doesn't allow them to break ABI when
> they need to, then it seems like they'll have no choice but to either
> remove the driver from upstream and only submit it when the ABI is
> stable, or fork the driver and submit a new one only when the ABI is
> stable.  Neither seem particularly attractive.

The thing is, they clearly didn't even _try_ to make anything compatible. 
See how all the ioctl numbers were moved around. 

And if you can't make if backwards compatible, at least you should make it 
forwards-compatible. Is it even that? I don't know. I'm kind of afraid it 
isn't. The new libdrm required for it certainly hasn't been pushed to 
Fedora-12. Will it ever be? And if it is, can you still run an old kernel 
on it?

All of these are always possible to do. We've been _very_ good at doing 
them in general. I'm complaining, because let's face it, what else can I 
do?

And btw, I'd complain about breaking backwards compatibility even if it 
wasn't just my own machine. I can pretty much guarantee that I'm not going 
to be the only one hitting this issue.

So practically speaking: what _do_ you suggest we do about all the 
regressions this will cause?

			Linus

Re: [git pull] drm request 3

[Dave Airlie]

>>
>> If marking the driver as staging doesn't allow them to break ABI when
>> they need to, then it seems like they'll have no choice but to either
>> remove the driver from upstream and only submit it when the ABI is
>> stable, or fork the driver and submit a new one only when the ABI is
>> stable.  Neither seem particularly attractive.
>
> The thing is, they clearly didn't even _try_ to make anything compatible.
> See how all the ioctl numbers were moved around.
>
> And if you can't make if backwards compatible, at least you should make it
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it
> isn't. The new libdrm required for it certainly hasn't been pushed to
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel
> on it?
>
> All of these are always possible to do. We've been _very_ good at doing
> them in general. I'm complaining, because let's face it, what else can I
> do?
>
> And btw, I'd complain about breaking backwards compatibility even if it
> wasn't just my own machine. I can pretty much guarantee that I'm not going
> to be the only one hitting this issue.
>
> So practically speaking: what _do_ you suggest we do about all the
> regressions this will cause?

At the moment in Fedora we deal with this for our users, we have dependencies
between userspace and kernel space and we upgrade the bits when they upgrade
the kernels, its a pain in the ass, but its what we accepted we needed
to do to get
nouveau in front of people. We are currently maintain 3 nouveau APIs
across F11, F12
and F13.

The main reason the API was gutted was because it supported lots of
things that weren't
supportable going forward. User modesetting support was completely
removed and this
meant lots of the API was pointless.

Now I can ask Ben if he'd like to try and supply a libdrm that could
in  theory deal
with both as a favour, but I'm not expecting the nouveau project guys
to care, we pretty
much got ourselves into this corner, and we'll pretty much have to get
ourselves out.

The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface
which justs ifdefs around this for now, and in another release or two
we rip all that out.

Of course I can't ask him either of these until normal people who live
in Australia wake
up in 2-3 hrs, as opposed to me who is sitting in the dark trying not
to wake the baby.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> At the moment in Fedora we deal with this for our users, we have 
> dependencies between userspace and kernel space and we upgrade the bits 
> when they upgrade the kernels, its a pain in the ass, but its what we 
> accepted we needed to do to get nouveau in front of people. We are 
> currently maintain 3 nouveau APIs across F11, F12 and F13.

Can we try to make it less of a pain in the ass at some other level?

For example, I realize that it's a real pain - both for the kernel _and_ 
for the user space library - to dynamically have to support multiple 
versions of some interface. 

And doing it _statically_ (with a compile option) isn't much better, 
because you end up not only with source code from hell, you still end up 
with the problem of having to compile the libraries and the kernel for the 
same interface, and not being able to mix.

So let's say that we live with an API that changes, where none of the 
binaries (and no single version of the source code either) really support 
anything but _their_ version of the interface.

Why does it then have to be such an effing pain for the _user_?

(And by being such an effing pain for the user, it also becomes indirectly 
a pain for the distribution too - now you have all those nasty 
dependencies where you really cannot mix things up at all, and you can't 
upgrade one piece without upgrading the other).

> Now I can ask Ben if he'd like to try and supply a libdrm that could in 
> theory deal with both as a favour, but I'm not expecting the nouveau 
> project guys to care, we pretty much got ourselves into this corner, and 
> we'll pretty much have to get ourselves out.

Quite frankly, I really don't think that's a wonderful option either. 
Havign dynamic conditionals in code not only makes things worse to 
maintain, they slow things down too, and make code bigger.

So what I'd look for is a sane technical solution to the technical problem 
of "that ABI screwed up". 

And it's not like this is a new issue. We've had this several times 
before. It's called versioning, and the solution tends to pretty much 
_always_ boil down to two cases:

 - don't _ever_ change the ABI in backwards-incompatible ways, and have 
   "feature flags" to say what level of support ther is.

   This is quite common, but it really does require that backwards 
   compatibility. You can add features, but every time you add a feature, 
   you still maintain the old ones _and_ new users need to check the 
   feature flag first (and fall back on the old way of doing things if the 
   new feature isn't there)

   Clearly this one doesn't seem to work for DRM. And quite frankly, I 
   suspect it's at least partly because some DRM people aren't even
   _trying_ - possibly because they aren't even thinking about these kinds 
   of issues.

 - Install multiple versions concurrently, and know they are incompatible, 
   but pick the right one automatically.

   I really don't understand why this wouldn't solve all your distro 
   problems, _and_ solve my kind of user problems too. It's simply not 
   acceptable to just say "ok, X doesn't work". Why aren't the libdrm 
   libraries simply _versioned_?

   IOW, why can't we just have 

	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so

   living happily side-by-side? Why can't we just switch between Fedora 
   11, 12 and 13 kernels, and automatically get the right library? The 
   glibc people do it based on hardware features. It's just a "dlopen()" 
   away.

This isn't rocket science. I shouldn't need to complain. I think it would 
make the life of even the _developers_ much easier.

Who was the less-than-rocket-scientist that decided that the right thing 
to do was to "check the kernel DRM version support, and exit with an error 
if it doesn't match"?

See what I'm saying? What I care about is that right now, it's impossible 
to switch kernels on a particular setup. That makes it effectively 
impossible to test new kernels sanely. And that really is a _technical_ 
problem.

Btw, I'm sure there are other approaches too. But I really suspect that it 
should be pretty trivial to change nouveau (and I suspect this has nothing 
nouveau-specific in it - it migth even be the X server itself that does 
the DRM version test) to instead of dying, just doing a dlopen() of the 
right version.

Wouldn't the radeon and intel driver people love to be able to do 
something like that -too-?

Seriously. The current situation is not just crap, it's _stupid_ crap.

		Linus

Re: [git pull] drm request 3

[Dave Airlie]

> Can we try to make it less of a pain in the ass at some other level?
>
> For example, I realize that it's a real pain - both for the kernel _and_
> for the user space library - to dynamically have to support multiple
> versions of some interface.
>
> And doing it _statically_ (with a compile option) isn't much better,
> because you end up not only with source code from hell, you still end up
> with the problem of having to compile the libraries and the kernel for the
> same interface, and not being able to mix.
>
> So let's say that we live with an API that changes, where none of the
> binaries (and no single version of the source code either) really support
> anything but _their_ version of the interface.
>
> Why does it then have to be such an effing pain for the _user_?
>
> (And by being such an effing pain for the user, it also becomes indirectly
> a pain for the distribution too - now you have all those nasty
> dependencies where you really cannot mix things up at all, and you can't
> upgrade one piece without upgrading the other).
>
>> Now I can ask Ben if he'd like to try and supply a libdrm that could in
>> theory deal with both as a favour, but I'm not expecting the nouveau
>> project guys to care, we pretty much got ourselves into this corner, and
>> we'll pretty much have to get ourselves out.
>
> Quite frankly, I really don't think that's a wonderful option either.
> Havign dynamic conditionals in code not only makes things worse to
> maintain, they slow things down too, and make code bigger.
>
> So what I'd look for is a sane technical solution to the technical problem
> of "that ABI screwed up".
>
> And it's not like this is a new issue. We've had this several times
> before. It's called versioning, and the solution tends to pretty much
> _always_ boil down to two cases:
>
>  - don't _ever_ change the ABI in backwards-incompatible ways, and have
>   "feature flags" to say what level of support ther is.
>
>   This is quite common, but it really does require that backwards
>   compatibility. You can add features, but every time you add a feature,
>   you still maintain the old ones _and_ new users need to check the
>   feature flag first (and fall back on the old way of doing things if the
>   new feature isn't there)
>
>   Clearly this one doesn't seem to work for DRM. And quite frankly, I
>   suspect it's at least partly because some DRM people aren't even
>   _trying_ - possibly because they aren't even thinking about these kinds
>   of issues.

We've done this exactly like this since the drm went upstream, I think
there has been one interface incompatible change in the kernel drm since
it was upstream, in i810 back in the XFree86 days. KMS required new config
options since moving the card init into the kernel, was going to break
or be broken
by a userspace driver reiniting that card, and we've retained compatiblity
with older drivers fine.

So you are tarring the whole drm with the interface to one driver
which is clearly
marked as having an unstable ABI. Nouveau is different, they have had no
reason to version or make a stable interface until they could design
an interface
that would expose the features of the hw that they are trying to build
a driver for.
They've also used the timing to drop all support for legacy user modesetting
drivers while they could, before it was deployed on a lot of people's machines
in a lot of places.


>   I really don't understand why this wouldn't solve all your distro
>   problems, _and_ solve my kind of user problems too. It's simply not
>   acceptable to just say "ok, X doesn't work". Why aren't the libdrm
>   libraries simply _versioned_?

This would require redesigning the whole way distros build and distribute
packages. Having to build 4-5 versions of nouveau for each version of Fedora
would be a major increase in overheads for a minimal amount of return.

>
>   IOW, why can't we just have
>
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
>        /usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so
>
>   living happily side-by-side? Why can't we just switch between Fedora
>   11, 12 and 13 kernels, and automatically get the right library? The
>   glibc people do it based on hardware features. It's just a "dlopen()"
>   away.
>
> This isn't rocket science. I shouldn't need to complain. I think it would
> make the life of even the _developers_ much easier.
>
> Who was the less-than-rocket-scientist that decided that the right thing
> to do was to "check the kernel DRM version support, and exit with an error
> if it doesn't match"?
>
> See what I'm saying? What I care about is that right now, it's impossible
> to switch kernels on a particular setup. That makes it effectively
> impossible to test new kernels sanely. And that really is a _technical_
> problem.
>
> Btw, I'm sure there are other approaches too. But I really suspect that it
> should be pretty trivial to change nouveau (and I suspect this has nothing
> nouveau-specific in it - it migth even be the X server itself that does
> the DRM version test) to instead of dying, just doing a dlopen() of the
> right version.
>
> Wouldn't the radeon and intel driver people love to be able to do
> something like that -too-?

Speaking as distro maintainer here,

No because we've got versioned interfaces and we are happy to support them
yes it would be nice sometimes to dream about this, but its a major explosion in
the testing matrix. You have to realise the more codepaths a distro ships, the
more codepath it has to keep track off for security issues, for bug fixes, etc.

When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
out it has a security issue? Here's the thing, distros are trying to ship an
OS with a consistent set of packages, not a pick-n-mix.

I'm going to talk to Ben when we both make it to the same place, from a
nouveau point-of-view I'm quite happy what they've done is technically the
correct solution for them, because otherwise you end up with too many
versions of things to support, and you get distros who aren't willing to put
any developer effort into the project, shipping 3 different versions of things,
(this happens with binary drivers, and its a nightmare).

The thing with redesigning the whole stack like you say, its you are optimising
for the wrong use case, this isn't a common case, this is one off
event that we've
been forced into by merging nouveau upstream. I'd rather not optimise
for this case
if we can get away with it.

Dave.

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Speaking as distro maintainer here,
> 
> No because we've got versioned interfaces and we are happy to support them
> yes it would be nice sometimes to dream about this, but its a major explosion in
> the testing matrix. You have to realise the more codepaths a distro ships, the
> more codepath it has to keep track off for security issues, for bug fixes, etc.

I think you're missing the whole point here. There's no new and complex 
"testing matrix". You only ever test the newest version, so there's no 
additional testing.

Here's the "inductive proof":

 - if the version number doesn't change, you aren't doing anything that is 
   at all different from what you already do.

 - if the version number _does_ change, it does so only because you 
   updated both the kernel component and the libdrm component together, 
   and you test them together - exactly like you already do.

So there is absolutely no difference for you. In either case, you only 
ever test paired up versions. If you make a new version, it will never 
_ever_ interact with old versions. There's no new complex testing needed.

The only thing it allows is for you to have multiple kernels installed 
simultaneously - and be able to _use_ them all. Which is something you 
already do.

And which the current model doesn't allow for. You may have three 
different kernels installed, but if libdrm got updated with a version 
change, only one of those kernels will actually _work_.

> When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> out it has a security issue?

Irrelevant and total red herring. You never care about older versions, 
since if people have updated, they are running the newer version.

So the older versions are there purely so that you _can_ have multiple 
different kernels, and so that your _developers_ can compile new kernels 
for older distributions. They aren't relevant for the case you point to: 
if somebody is just doing "yum update", they'll get - and use - the newer 
version anyway.

> Here's the thing, distros are trying to ship an OS with a consistent set 
> of packages, not a pick-n-mix.

But here's the thing: if you expect people to do development, they _need_ 
to be able to mix things. A kernel developer needs to be able to update 
their kernel. And a kernel _tester_ needs to be able to test that kernel.

Seriously: what do you expect me to do right now in my situation?

I'm not going to release a kernel that I can't test. So if I can't get a 
libdrm that works in my F12 environment, I will _have_ to revert that 
patch that you asked me to merge.

Really. Look at it from my standpoint. Look at it from _any_ kernel 
developer standpoint. It would be totally irresponsible of me to release 
2.6.34 without even eating my own dog-food on my own main machine. Can't 
you see that this is obviously true?

So right now, I'm running with that patch reverted on that machine. I 
haven't committed the revert, and quite frankly, I'd really prefer not to. 
But the only way that "not revert" case can really happen is if there is 
some other way for me to have a working machine again.

Think about it. Tell me what the solution is.

		Linus

Re: [git pull] drm request 3

[Ben Skeggs]

On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote:
> 
> On Fri, 5 Mar 2010, Dave Airlie wrote:
> > 
> > Speaking as distro maintainer here,
> > 
> > No because we've got versioned interfaces and we are happy to support them
> > yes it would be nice sometimes to dream about this, but its a major explosion in
> > the testing matrix. You have to realise the more codepaths a distro ships, the
> > more codepath it has to keep track off for security issues, for bug fixes, etc.
> 
> I think you're missing the whole point here. There's no new and complex 
> "testing matrix". You only ever test the newest version, so there's no 
> additional testing.
> 
> Here's the "inductive proof":
> 
>  - if the version number doesn't change, you aren't doing anything that is 
>    at all different from what you already do.
> 
>  - if the version number _does_ change, it does so only because you 
>    updated both the kernel component and the libdrm component together, 
>    and you test them together - exactly like you already do.
> 
> So there is absolutely no difference for you. In either case, you only 
> ever test paired up versions. If you make a new version, it will never 
> _ever_ interact with old versions. There's no new complex testing needed.
> 
> The only thing it allows is for you to have multiple kernels installed 
> simultaneously - and be able to _use_ them all. Which is something you 
> already do.
> 
> And which the current model doesn't allow for. You may have three 
> different kernels installed, but if libdrm got updated with a version 
> change, only one of those kernels will actually _work_.
> 
> > When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> > out it has a security issue?
> 
> Irrelevant and total red herring. You never care about older versions, 
> since if people have updated, they are running the newer version.
> 
> So the older versions are there purely so that you _can_ have multiple 
> different kernels, and so that your _developers_ can compile new kernels 
> for older distributions. They aren't relevant for the case you point to: 
> if somebody is just doing "yum update", they'll get - and use - the newer 
> version anyway.
> 
> > Here's the thing, distros are trying to ship an OS with a consistent set 
> > of packages, not a pick-n-mix.
> 
> But here's the thing: if you expect people to do development, they _need_ 
> to be able to mix things. A kernel developer needs to be able to update 
> their kernel. And a kernel _tester_ needs to be able to test that kernel.
Here's the thing.  *You* pushed for nouveau to go into staging before
any of the developers were ready for it.  Two of the big reasons (from
my POV) for not requesting inclusion were the context programs (which
have since been dealt with) and that yes, we have no intention of
keeping crusty APIs around when they aren't what we require.

The idea of staging was to allow for exactly the second problem, so why
are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
expect that for the most part people will be using our packages, which
deal with the ABI issues.

> 
> Seriously: what do you expect me to do right now in my situation?
> 
> I'm not going to release a kernel that I can't test. So if I can't get a 
> libdrm that works in my F12 environment, I will _have_ to revert that 
> patch that you asked me to merge.
The F13 packages *will* work, so long as you're not bisecting back and
forth.

> 
> Really. Look at it from my standpoint. Look at it from _any_ kernel 
> developer standpoint. It would be totally irresponsible of me to release 
> 2.6.34 without even eating my own dog-food on my own main machine. Can't 
> you see that this is obviously true?
With the release of 2.6.34 it'll require people to update userspace
*once*, if they're rolling their own kernels and not using distro
provided packages they should be able to handle that much.

I agree it's a pain to bisect through, really.  But it's far far from
the common use case.

Ben.

> 
> So right now, I'm running with that patch reverted on that machine. I 
> haven't committed the revert, and quite frankly, I'd really prefer not to. 
> But the only way that "not revert" case can really happen is if there is 
> some other way for me to have a working machine again.
> 
> Think about it. Tell me what the solution is.
> 
> 		Linus
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Ben Skeggs wrote:
> 
> The idea of staging was to allow for exactly the second problem, so why
> are you surprised?  The fact Fedora ships nouveau is irrelevant, we also
> expect that for the most part people will be using our packages, which
> deal with the ABI issues.

The fact that Fedora ships nouveau is _not_ irrelevant.

That fact was what made it so important to get it merged. The distro rules 
wrt the kernel have been (for _years_ - before nouveau was ever even used 
by Fedora) that whole "upstream first".

I don't understand how you can even call it irrelevant. The very fact that 
Fedora started using Nouveau was - and is - the whole reason for this 
issue. 

> > I'm not going to release a kernel that I can't test. So if I can't get a 
> > libdrm that works in my F12 environment, I will _have_ to revert that 
> > patch that you asked me to merge.
>
> The F13 packages *will* work, so long as you're not bisecting back and
> forth.

How do I install just the F13 libdrm thing, without changing everything 
else? I'm willing to try. We can make it part of the 2.6.34 release notes.

And if we end up having people bisecting back and forth, I will hate that 
f*cking nouveau driver even more.

				Linus

Upstream first policy

[Kyle McMartin]

On Thu, Mar 04, 2010 at 04:41:19PM -0800, Linus Torvalds wrote:
> That fact was what made it so important to get it merged. The distro rules 
> wrt the kernel have been (for _years_ - before nouveau was ever even used 
> by Fedora) that whole "upstream first".
> 

As nice as that is, I'm not sure *any* real distro follows it. (Ok,
Gentoo seems to only ship ~100K of diff in their genpatches dir[1],
good on them.)

We *try* to only merge things in Fedora that will be heading upstream
quickly, or are backports from -next. Things occasionally, you know,
don't, like the execshield crap, lirc, and utrace.

Nouveau, you obviously know about, I think Adam merged it into Fedora
for the sole reason of providing a slightly less crap experience for
Nvidia cards prior to G80 where the nv driver got slightly better.
(Though, obviously Nouveau is now compelling for more reasons than just
being able to light up a second head.) This is obviously now more
difficult now that nouveau binds by default on boot with KMS.

It would be /great/ if we had more people cleaning up staging drivers
so that more stuff could go in there. But it seems people are more
interested in re-indenting code than actually fixing things. (I can
understand a certain reticence to this, since it's sometimes hard to fix
real problems in drivers if you can't test it.) I'm not sure what the
latest round of staging changes looks like off hand, but I'm going to
guess that more stuff was punted for unmaintenance than graduated to the
kernel proper by a large factor.

regards, Kyle

I recommend you don't look at Ubuntu, we might have a lot of extra
crud[2] in the kernel if you do. :) (Actually, shockingly less than I
thought, just apparmor, aufs, ndiswrapper are the obvious ones.)

1. http://dev.gentoo.org/~mpagano/genpatches/trunk/2.6.32/
2.
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=tree;f=ubuntu

Re: Upstream first policy

[Linus Torvalds]

On Thu, 4 Mar 2010, Kyle McMartin wrote:
> 
> I recommend you don't look at Ubuntu, we might have a lot of extra
> crud[2] in the kernel if you do. :) (Actually, shockingly less than I
> thought, just apparmor, aufs, ndiswrapper are the obvious ones.)

Ok, so ndiswrapper falls under the "yeah, no" heading.

But apparmor was supposed to be on the "yeah, we'll merge it" path, I 
talked to somebody about it not _that_ long ago. Some of the security 
people object, but they object for all the wrong reasons and I really do 
think that since it's getting used, we really should merge it.

Although there was _some_ noise about Ubuntu trying to move away from it.. 
But that may have been more of the whole FUD thing from the people who for 
some unfathomable reason think that inodes are more important than 
pathnames.

aufs I'll leave at Al's mercy. 

			Linus