[MPlayer-dev-eng] [PATCH] adjusting nice level from config/command line

[Wojtek Kaniewski]

On Mon, 27 May 2002, Brian J. Murrell wrote:
> > because it's uncomfortable. you could decode some video stream to raw
> > rgb frames and put them on the screen as well, but i suppose you don't
> > watch movies that way. yes, i could run mplayer as root, but that's not
> > the way.
> 
> Instead, provide a binary that will allow anyone that can get at your
> box r00t it?  That is just silliness.

who says that mplayer will be suid-root by default? it's suid-root ONLY
on those systems, whose admins understand what it is needed for.

> > could you point any errors in this patch?
> 
> Well, you are advertising that with your patch, you can suid-root
> MPlayer.

you can do it without my patch as well *g*

> I don't see anywhere in your patch where you give up root
> permissions after you have done everything you need to do as root.

the patch itself does not require root permissions. it only changes
process priority. if someone wishes to increase the priority, he can
(but IS NOT forced to) make it suid-root. he can also use some kernel
module that gives CAP_SYS_NICE to /usr/wherever/bin/mplayer binary.
the suid was just an _example_. i also gave url to the kernel module that
allows to give some specified capabilities to a particular binary.

> The basics of suid-root is to immiately do whatever you need root
> access to do and then to drop root priviledges (back to the user that
> owns the process) so that the process cannot be used to exploit the
> machine.

i know that very well. but it's not my task to make mplayer secure when
running as root, as my patch has nothing to do with it.

> > i don't understand why it is
> > ,,improper and insecure''.
> 
> Because with your patch, the process _never_ gives up root privillege.
> Very bad.

again, the patch DOES NOT require root privileges.

> That means that every line of MPlayer code could
> potentially give a non-root user root access.  However if the first
> thing main() did was your nice() then dropped root privillege, the
> security risk is much mitigated.

mplayer needs uid 0 for many other things, mostly initialization of
video output plugins. i'm not going to secure mplayer. it's not my job,
i'm don't feel authorized, and i lack of knowledge about mplayer's
internals.

> > the documentation already points that making mplayer a suid executable
> > is insecure on DGA's example. well, why don't just remove DGA support?
> > isn't it improper and insecure?
> 
> I don't know the details of DGA and why giving root for it's access is
> insecure so I can't comment on this.

well, it's seems that you haven't read the docs *eg*. the docs say:

   Become ROOT. DGA needs root access to be able to write directly video
   memory. If you want to run it as user, then install MPlayer SUID root:

   (...)

   !!!! BUT STAY TUNED !!!!
   This is a BIG security risk! Never do this on a server or on a computer
   can be accessed by more people than only you because they can gain root
   privilegies through suid root mplayer.
   !!!! SO YOU HAVE BEEN WARNED ... !!!!

and of course, mplayer does not drop root priviledges. why don't you
complain about this part of the code and don't blame mplayer developer
for making it insecure? 

(and if other subscribers are feeling bored by this thread or think that
this discission leads nowhere, i can shut up. just nod or something.) 

regards,
wojtek