Re: [PATCH v2 resend] vfs: new O_NODE open flag

From: Pavel Machek
Date: Mon Nov 09 2009 - 03:58:21 EST


On Fri 2009-11-06 12:55:33, Eric W. Biederman wrote:
> Pavel Machek <pavel@xxxxxx> writes:
>
> > On Thu 2009-11-05 15:27:06, Miklos Szeredi wrote:
> >> On Thu, 5 Nov 2009, Alan Cox wrote:
> >> > > - re-opening normally after checking file type (there's a debate
> >> > > whether this would have security issues, but currently we do allow
> >> > > re-opening with increased permissions thorugh /proc/*/fd)
> >> >
> >> > Which has already been demonstrated to be an (unfixed) security hole.
> >>
> >> No it hasn't :) Jamie theorized that there *might* be a real world
> >> situation where the application writer didn't anticipate this
> >> behavior. But as to actual demonstration, we have not seen one yet, I
> >> think.
> >
> > See bugtraq, or lkml thread about symlinks with permissions. There's
> > demo script there.
>
> Exactly a theoretical discussion, that demonstrates user space
> applications with security holes can be written if they make
> assumptions about the world that are not true.
>
> So far no one who believes this to be a security hole has found it
> worth their while to look at nd->intent.open in proc_pid_follow_link
> and write a patch. Pavel you started out asking for help on how
> to do that and I think I have answered the original question.


> I am tired of the whining. If no one who is persuaded the kernel is
> wrong can be bothered to write a possibly buggy 5 line patch this is
> clearly not a security hole.

"I did not get a patch so it can't be security hole". Interesting.

I still hope to write it one day, but as I do not have untrusted users
on my systems, it is not particulary urgent. (And I still hope distro
security people do they job.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/