Bad file access on the rise

Lennart Poettering mzerqung at 0pointer.de
Fri Jun 7 16:55:46 UTC 2013


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.

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

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

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list