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