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 at EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

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