ainit

[Russell Coker]

The attached patch is needed for correct functionality of ainit with the 
latest strict policy when running reasonably recent rawhide packages.

Is this really what we want?  Having a system process allocate shared memory 
that can be used by any user processes?  Also it seems likely that other 
sound programs will need to access the shared memory in question.

There are three possible assumptions that we could make:

1)  Anyone who is serious about security doesn't use ALSA so such access 
doesn't matter that much.

2)  Sound devices are a channel for communication anyway so it doesn't really 
grant any new access.  NB  I don't know enough about sound programming to 
know whether this assumption is correct.  Does ALSA require that a shared 
memory segment be available to all programs that are accessing the sound 
device?  If so the assumption holds for ALSA.  Can an application stuff some 
data into the sound hardware without using the user-space code from ALSA in 
such a way that another application can read it?

3)  We need to have pam_console launch programs such as ainit in a context 
determined by the user role.


Option 3 might be the best one long-term.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Christopher J. PeBenito]

On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote:
>  Is this really what we want?  Having a system process allocate shared
> memory 
>  that can be used by any user processes?  Also it seems likely that other 
>  sound programs will need to access the shared memory in question.
>  
>  There are three possible assumptions that we could make:
>  
>  1)  Anyone who is serious about security doesn't use ALSA so such
>  access doesn't matter that much. 
This isn't the case.  ALSA isn't any different then OSS from a SELinux
viewpoint.  I don't have ainit on any of my Gentoo machines; after a few
minutes on Google, it seems that this is a Redhat/Fedora specific
program.

>  2)  Sound devices are a channel for communication anyway so it
> doesn't
>  really grant any new access. 
I don't see any SysV IPC objects on my machines that use ALSA, so it
seems that ALSA has an optional feature that uses IPC, but it is not
required for playing or recording sound.

>  Does ALSA require that a shared memory segment be available to all
>  programs that are accessing the sound device? 
This is the important question to ask of this feature.

>  Can an application stuff some data into the sound hardware without
>  using the user-space code from ALSA in such a way that another
>  application can read it? 
Adding in shared memory access between all user domains is a much easier
channel for communication then a sound device is; it doesn't need to go
through the hardware since all user domains can read and write the
segments.

>  3)  We need to have pam_console launch programs such as ainit in a
> context 
>  determined by the user role. 
Probably the right answer if the shared memory doesn't have to be shared
between all user domains.

-- 
Chris PeBenito
Tresys Technology, LLC
[phone] x150

[Colin Walters]

On Thu, 2005-07-21 at 10:50 -0400, Christopher J. PeBenito wrote:
>  On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote:
>  > Is this really what we want?  Having a system process allocate shared memory 
>  > that can be used by any user processes?  Also it seems likely that other 
>  > sound programs will need to access the shared memory in question.
>  > 
>  > There are three possible assumptions that we could make:
>  > 
>  > 1)  Anyone who is serious about security doesn't use ALSA so such
>  > access doesn't matter that much.
>  
>  This isn't the case.  ALSA isn't any different then OSS from a SELinux
>  viewpoint.  I don't have ainit on any of my Gentoo machines; after a few
>  minutes on Google, it seems that this is a Redhat/Fedora specific
>  program. 
At the moment possibly, but I'm sure other systems will want to unbreak
their sound eventually too :)

>  Probably the right answer if the shared memory doesn't have to be
> shared
>  between all user domains. 
It needs to be accessible to any program that wants to play sound.

[Colin Walters]

On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote:
>   Does ALSA require that a shared 
>  memory segment be available to all programs that are accessing the sound 
>  device?  
This is a consequence of switching to the ALSA "dmix" device by default,
which does transparent sound mixing in userspace via the shared memory.
This fixes the extremely user-visible bug of multiple applications not
being able to use the sound card at the same time.

Fundamentally though the IPC key doesn't have to be allocated by the
system; I wrote some code a while back that would have allocated it as
part of the X login, all in the normal user session so there was no
"system" part involved.  I'm still not sure why our ALSA maintainer
chose the ainit/PAM route given that you don't care about sound mixing
for any other means of logging in like ssh or virtual terminal.  Or at
least, I don't think we should care.

[Casey Schaufler]

--- Russell Coker <russell(a)coker.com.au&gt; wrote:


>  1)  Anyone who is serious about security doesn't use
>  ALSA so such access 
>  doesn't matter that much. 
This is always a bad assumption, regardless
of the facility in question.




Casey Schaufler
casey(a)schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Stephen Smalley]

On Thu, 2005-07-21 at 21:42 +1000, Russell Coker wrote:
>  The attached patch is needed for correct functionality of ainit with
> the 
>  latest strict policy when running reasonably recent rawhide packages.
>  
>  Is this really what we want?  Having a system process allocate shared memory 
>  that can be used by any user processes?  Also it seems likely that other 
>  sound programs will need to access the shared memory in question. 
Not a good idea.  Look at nscd handling for its shmem interface; we use
an attribute to allow certain domains such access, but most domains are
limited to the socket IPC-based interface.  This program should likewise
have some kind of fallback to an IPC-based interface if the shmem
interface isn't allowed.

-- 
Stephen Smalley
National Security Agency