Bad file access on the rise

[Simo Sorce]

On Fri, 2013-06-07 at 18:55 +0200, Lennart Poettering wrote:
> On Fri, 07.06.13 12:42, Simo Sorce (simo at redhat.com) wrote:
> 
> > On Fri, 2013-06-07 at 18:21 +0200, Lennart Poettering wrote:
> > > On Fri, 07.06.13 12:09, Steve Grubb (sgrubb at redhat.com) wrote:
> > > 
> > > > > > > POSIX shared memory doesn't define any useful scheme for automatic
> > > > > > > removing of shared memory segments from /dev/shm after use. Hence, in
> > > > > > > order to make sure that left-over segments don't fill up /dev/shm
> > > > > > > forever PA will try to GC dead segments from /dev/shm on each
> > > > > > > start-up. For that it iterates through /dev/shm/pulse-shm*, tries to
> > > > > > > read the PID that is stored in there.
> > > > > > 
> > > > > > Maybe the uid can be encoded in the name so that wrong uid's are
> > > > > > skipped?
> > > > > 
> > > > > But why?
> > > > 
> > > > So that you are not filling up the audit logs. There are people that have to 
> > > > use these audit rules and we need a normally operating system to produce as 
> > > > few false positives as possible.
> > > 
> > > Maybe the audit system should be fixed to not trip up by this? 
> > 
> > Lennart,
> > it's fun to troll, but seriously, the audit system *audits*, it's not
> > hard to understand.
> 
> Well, you know, this problem isn't new. Some SELinux AVCs can be set to
> ignored for precisely reasons like this one, because it is common that
> things like these happen: accesses which fail where that is
> expected. You can call me a troll as much as you want, but then please
> call the Selinux folks trolls first.

The SELinux folks, being the practical bunch they are simply work around
bad programs. That doesn't mean they are trolls.
Also the SeLinux folks have 'context', which is something an audit
system may not have.
Finally the fact SELinux folks are considerate does not mean that
programs need not be fixed to behave better.

Of course the author can always decide to show the finger and do what he
wants anyway, we live in a free and unpolite world after all.

> > > Guessable directory names in a world-writable directory? I am sorry,
> > > that's not an option. The stuff is already DoS-able enough, I am pretty
> > > sure I don't want to open the door even wider. (Also what is this,
> > > anyway? of all people, you as a security guy should know what bad an
> > > idea that is...)
> > 
> > Sorry but what makes /dev/shm/pulse-shm-3756395503 more/less guessable
> > than /dev/shm/<uidnumber>/pulse-shm-3756395503 ?
> 
> User "simo" creates /dev/shm/1000/ even though 1000 is the UID of user
> "lennart". Lennart can never start PA again, ever. And can't do anything
> about it, because "simo" is in control, and /dev/shm is sticky.

That could be solved by precreating the directory at login time, like we
do for many other things. There isn't just one way.
Or you could even stop using /dev/shm and we'd have one less problem
entirely :)

The point is that we are simply throwing ideas off the wall as an aid in
finding a way to solve the issue for all.

> It's really disappointing if people as seasoned as you still don't
> understand these shared-namespace issues of world-writable directories. 

Yeah, just like it is disappointing to see that your first reaction is
always to show the finger hard and solid instead of trying to have a
reasonable discussion about the problem.

> > > > There are ways to make this better if you are willing.  :-)
> > > 
> > > Well, or you could make audit better, if you are willing.
> > 
> > Or you could actually listen.
> 
> Well, so far you didn't make a very convincing point, did you?

That is entirely possible, but it doesn't look like you are making one
either.

Steve asked a pretty simple question, based on clear premises.

You could have simply explained why you can't change it or solicited
ideas, instead you attacked him and replied as if Steve had accused you
of something awful. And of course you extend the same courtesy to anyone
else who dares offering some ideas. This is not the way to discuss
technical problems.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York