audio permissions quandary

audio permissions quandary

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.

I want to do something simple, I want to have my local mail delivery
software, maildrop, play a sound, depending on from who a particular mail
message arrives. Simple, right? Well, not really, as I'll describe
below.

Maildrop runs suid root, -rwsr-xr-x 1 root daemon 162208 May 18 01:35
maildrop, which its author says is safe, and in fact encouraged for
a couple of reasons, since maildrop takes on the uid/gid of the user whose
mailbox it's delivering mail to. I have verified this, by writing up a
small program that outputs the uid, gid, effective uid, and effective
gid, and I ran this program inside my $HOME/.mailfilter, and it does
get run as user greg, and group greg, effective and otherwise.

So, coming back to what I want to do, I have in my $HOME/.mailfilter
several if statements, each of which invokes aplay to play a specific
sound file. When user greg, who has access to the audio group, runs
aplay from the shell prompt, everything works as expected. However,
when aplay gets run by maildrop, I get no sound, and the below
message:

ALSA lib confmisc.c:769:(parse_card) cannot find card ''
ALSA lib conf.c:3510:(_snd_config_evaluate) function
snd_func_card_driver returned error: No such device
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_concat
returned error: No such device
ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name
ALSA lib conf.c:3510:(_snd_config_evaluate) function snd_func_refer
returned error: No such device
ALSA lib conf.c:3982:(snd_config_expand) Evaluate error: No such
device
ALSA lib pcm.c:2144:(snd_pcm_open_noupdate) Unknown PCM default
aplay: main:545: audio open error: No such device

Although user greg has access to the audio group, it seems that
maildrop, and any other programs that get invoked from it, run only as
user greg, group greg. What it boils down to is that aplay doesn't
have access to the audio hardware, when it is run by maildrop. I have
thought of a couple solutions for this, but don't like what I've come
up with so far.

1. Make aplay run suid root, which actually does work, in terms of
playing audio when aplay is run by maildrop. However, this approach is
problematic. At best, anyone with an account on this system can decide
to annoy me by playing stuff via aplay on the system. This activity
would piss me off sooner or later, (probably sooner), resulting in
the suspension of the culprit's account. At worst, someone can
exploit a future security whole in aplay, and gain access on the
system as root.

2. Another solution is to make the audio hardware writable to everyone
on the system. While this would solve the problem of future possible
security wholes in aplay, it would still mean that anybody with an
account here could be obnoxious, with a wider range of audio players
to use besides.

I've also tried copying aplay to greg's $HOME/bin directory, and
making that copy suid root, but that gives me the same error message as
above, when run by maildrop. I suppose I could make greg own the audio
hardware exclusively, but then what about programs like espeak for
example, or other users who might need audio access on this system in
the future for some reason? Any ideas on securely working around this
problem, thus allowing aplay to access the audio hardware when run by
maildrop, would be much appreciated, and thanks in advance as always.

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHCbdg7s9z/XlyUyARAtfVAJ45Nbphs7n62Rb1oQjsKtICvDtYtgCeJIOQ
yM1jGo0T75JieXjIJ8NaKCY=
=6CmV
-----END PGP SIGNATURE-----

Re: audio permissions quandary

[Frank Carmickle]

Hi Greg

After beeting on this for three hours I have a solution but I don't like it to much.  It's better then suid though.  Use sudo with a line like this in your sudoers file

greg ALL= (greg) NOPASSWD:/usr/bin/aplay

then drop in your .mailfilter file
`sudo -u greg aplay somefile`

Like I said I don't like it that much but it does work and it doesn't allow anyone else to use aplay who isn't you.  It also runs aplay as you.

HTH
--Frank

Re: audio permissions quandary, part 1

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Frank and all.

Thanks for your suggestion. I actually e-mailed a friend of mine as
well with this, who isn't on this list, and here's what his
suggestions were:

"Isn't maildrop marvellous?

The problem: maildrop doesn't set your supplemental group privileges
when
it changes its euid and egid according to the -d option.

Solutions I can think of:

1.  Change maildrop so it does that, or ask someone else interested
    enough
to do it.  I don't see where the problem is in doing that from a
    security
point of view provided that the login program and set supplemental
    groups
together don't grant permission for access to hardware not appropriate
    for
all users that use maildrop.  For instance, a mailinglist manager
    using
maildrop ought not get privileges to access pseudoterminals.  I
    personally
think letting anyone not a real user use maildrop is a mistake anyway.
Use delivery to programs if you want a user to get mail for automated
processing and have the MTA either execute setuid binaries or switch
    euid
itself before executing the program.

2.  As root, put a device node for your audio device into your home
directory, then arrange for only you to have read-write on the device.
Change ownership on the device to your unprivileged user.  Make your
audio
program use this device instead (specify the full path from maildrop).

3.  Use a safe setuid root program to get at the device.  Consider
    beep,
for instance, which is quite hard to break.  You won't, of course, be
    able
to use a supplemental group to make beep work for a subset of users,
    and
so you're still liable to be pissed off, but less so than with sound
hardware.

4.  Truely a last resort.  Make sure your MTA switches user and sets
supplemental groups itself before running maildrop (necessitates
having
root privileges to play with more-or-less the whole time), without the
- -d
option.  Sendmail runs this way by default if you don't set the
RunAsUser
option on the daemon, although this botches local deliveries made with
unprivileged sendmail invokations done locally.  If you won't/can't do
that, the next best thing is to write a small program, make it setuid
root
and readable only by the MTA, which takes a user and argv vector like
setuidgid.  Such a program can be invoked by a nontrusted MTA, switch
uid,
then run your MDA with enough privileges to be useful.  This is
essentially what I do: sendmail is untrusted, runs setuidgid with the
user
so that maildrop runs with users' privileges.  Maildrop has that code
already, but this is more portable to other, potentially less
trustable,
MDAs.  The downside is that unless I'm being targetted by a
non-specific
attack against sendmail, the attacker has a tool he can use to get
unlimited privileges.  If he can make a run of setuidgid as root once
gaining the sendmail smmsp account, he can do bad things.  Assumes, of
course, that the attacker knows this is necessary and that sendmail is
exploitable enough to grant such access.
 "
 
- --- part 2 to follow ---

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDRwE7s9z/XlyUyARAgepAJ9Nkj6md24V7le0c7aF1P36zJdrkACfWsIV
fYC8RN1k9OcPMQXEuJKI/4Q=
=gXeI
-----END PGP SIGNATURE-----

Re: audio permissions quandary, part 2

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The second suggestion seemed very attractive, until I got lost on how
to do that after some effort, given that udev is involved, and that
dmix is being used, and documentation for alsa seems to be
nonexistent. On top of that, I found that if I change

defaults.pcm.ipc_gid audio

to say

defaults.pcm.ipc_gid greg

, or any other group for that matter in /usr/share/alsa/alsa.conf, the
devices are still in the audio group, even after a reboot.

I was considering looking at the maildrop source this morning, and
seeing if I could implement suggestion #1, and submit a patch to the
author, but since at this point I'm looking for the easiest suggestion
to implement with the least security compromise, if any, I'll try your
suggestion before resorting to playing with the maildrop source. It
isn't perfect as you said, but the worst that can happen is that
somebody exploits a future security whole in aplay, and gets access as
greg on the system. That's still not good, but it's better than
exploiting aplay, and getting root access as the prize.

After doing some web searching, I must say I'm surprised that nobody
has pointed out this limitation before. After all, wanting to play
certain sounds depending on who mail comes from isn't that unheard
of. Thanks again.

Greg


On Wed, Oct 10, 2007 at 03:27:09AM -0400, Frank Carmickle wrote:
> Hi Greg
>
> After beeting on this for three hours I have a solution but I don't
like it to much.  It's better then suid though.  Use sudo
+with a line like this in your sudoers file
>
> greg ALL= (greg) NOPASSWD:/usr/bin/aplay
>
> then drop in your .mailfilter file
> `sudo -u greg aplay somefile`
>
> Like I said I don't like it that much but it does work and it
doesn't allow anyone else to use aplay who isn't you.  It also
+runs aplay as you.
>
> HTH
> --Frank
>


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDRyy7s9z/XlyUyARAv4IAJ98AGdpByrns5hZuHF42mzPbdgQzwCgkzlV
+pKXvqp+e27NpdBww+XeCQM=
=98sY
-----END PGP SIGNATURE-----