review qemplayer (was Re: Please review my package)

[IOhannes m zmoelnig]

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

hi.

is it possible for you to "reply" to messages, so threads are kept intact?
also it would be nice if you could use a more meaningful subject ("my"
package refer to a number of packages, non of which is qemplayer)


On 2012-07-05 22:14, wbrana wrote:
>> That doesn't change that it is a security hazard! Don't run user
>> apps as root! Don't implement super-user features in user apps -
>> implement it separately, and make it optional to use it.
> I don't run user apps as root. MPlayer is never started as root.

by setting the setuid flag, you _are_ running mplayer_nice as root.

> 
> Here is mplayer_nice source code with comments:
[...]

this doesn't mean anything.

if your application is dropping root priviges as soon as it can, it
still _has_ root priviliges at some point. if the binary can be
compromised in a critical state, this means that the an attacker can
get easy root access to your machine.

> Google Chrome is also using setuid binary XOrg server is also
> setuid binary


you might want to contact the packagers of google chome and xorg about
that (and they most likely will either fix the problem or have a very
good explanation why they need setuid)


> According to http://linux.die.net/man/5/limits.conf it is possible
> to enable low niceness for all processes started by all/some
> user(s), but it isn't possible to limit it to mplayer_nice if
> started by any user
> 

so why do you not want to use it?
do you think you are granting too much priviliges to "all/some
user(s)" when using pam_limits?
if so, please consider:
- - why exactly does mplayer_nice need root priviliges?
- - setuid'ing your binary grants the application super-user priviliges.
among those are realtime-priorities, reading /etc/passwd and the like.
setuid'ing grants all those priviliges.
- - pam_limits allows you to fine-tune those priviliges on a per-user
basis. e.g. you can grant access to realtime-priorities, but not to
reading /etc/passwd or to /dev/null'ing your harddisks.
- - pam_limits works on a per user (per group) basis. this is the
traditional un*x way to handle security. consider an attacker who
gains access to your machine as an unpriviliged user (eg. "www-data").
they can then simpy run /usr/bin/mplayer_nice to gain root access of
your machine. with pam_limits, they first need to become a given
user/group-member before they can start _any_ application with
realtime priorities. this is bad enough, but not as the first scenario.
- - check your /etc/security/limits.d/audio.conf
chances are high that you already have this file and that it grants
members of the audio group enough rights to run your application as
you want it to run.
i guess that all users interested in running (and supposed to run)
mplayer_nice are already in the "audio" group.
- - ...


gsdfmrt
IOhannes





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/6g+YACgkQkX2Xpv6ydvQzFgCfe2fdPylxw1yM0LZ0OHeepFVC
S/8AoJ83WeVkNWeJuEvozLTe6bU8McvT
=YqkY
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2320 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20120709/c89562db/attachment.bin>