From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 19 Oct 2012 20:45:11 +0200
Subject: [refpolicy] [REVIEW REQUEST] Changes to the pulseaudio policy
 module and its dependencies
In-Reply-To: <1350670399.12496.24.camel@d30.localdomain>
References: <1350667422-9219-1-git-send-email-dominick.grift@gmail.com>
	<20121019180055.GA11667@siphos.be>
	<1350670399.12496.24.camel@d30.localdomain>
Message-ID: <20121019184511.GA14349@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, Oct 19, 2012 at 08:13:19PM +0200, Dominick Grift wrote:
> > I have a similar construction with alsa. One thing I am hoping to look into
> > soon is a "What if /dev/shm was shm_tmpfs_t instead of tmpfs_t", would that
> > make sense?
> > 
> > It would tighten the scope of such "wide" tmpfs file accesses.
> 
> pulseaudio clients create that pulse-shm file in /dev/shm with a private
> type, i do not see how this would help?
> 
> programs that use pulse and that run in the userdomain create those
> files with user_tmpfs_t
> 
> So all they need with regard to tmpfs_t is search tmpfs_t dirs, add and
> remove dir entries from tmpfs_t dirs and get attributes of tmpfs_t
> filesystems

It's mainly for reducing the scope. If pulseaudio clients automatically have
their tmpfs types be writeable by other pulseaudio clients, then also
non-shm related tmpfs files are affected by this.

If we'd use a specific type for shared memory (like shm_t) then other tmpfs
files are not "opened up".

It's a fairly intrusive change for a small gain, I understand (many policies
will need to be adapted for this, whereas there aren't that many tmpfs
locations on a system I think that are actually labeled as tmpfs_t). Hence
the "look into" part of the suggestion ;)

Wkr,
	Sven Vermeulen