Bad file access on the rise

Lennart Poettering mzerqung at 0pointer.de
Fri Jun 7 16:21:00 UTC 2013


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? 

> > This stuff should be simple, and it's always a better idea to
> > simply let the kernel do EACCES rather then trying to be smarter than
> > the kernel and reimplement access control in userspace.
> 
> Well, you are already trusting the name. Who's to say some rougue process 
> didn't create the file name to try and trick pulseaudio? 

Well, if the process did that, then we'd just delete his shared memory
block. I don't feel particularly tricked there... ;-) And besides that,
note that PA also checks a file signature before deleting the file, just
to be sure to not delete anything of importance...

> How about doing like some processes do in the /tmp dir...put the
> segments in a directory /dev/shm/<user name>/ and then scan all the
> files that belong to that user?

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

> There are ways to make this better if you are willing.  :-)

Well, or you could make audit better, if you are willing.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list