Icecast - Oct 2004 - [Jackit-devel] Re: ices-kh dropping jack ports unexpectedly

On Mon, 2004-10-18 at 22:14, Paul Davis wrote:
> jackd (realtime) requires various resources which it shares with its
> clients:
> 
>       realtime scheduling
>       mlock-ability
>       shared memory segments
>       FIFOs (or Mach ports on OS X)
> 
> we consider it *more* of a security risk to allow jackd-as-root to
> share these with non-root processes. YMMV.
Whenever communication is done to an as-root app then the risk *is*
increased (I treat that as fact). The point I was making with ices is
that realtime scheduling is the only aspect that requires root (in
general).  For jackd I can see mlock being a possible problem if you
dropped root privs, mlockall should be ok, but I haven't done much with
that.
> >What I can say is that ices tries to acquire realtime scheduling if
> >enabled (default is yes) which may or may not fail, but if root is used
> 
> what ices does is mostly irrelevant to JACK. the thread that handles
> audio processing is created by JACK, and that thread does not inherit
> any scheduling parameters from its parent. whether other ices thread
> run SCHED_FIFO is besides the point, and probably should be discouraged.
There are still timing/latency considerations with ices and not just for
things relating to JACK.
> >that user, and therefore _NOT_ run as root anymore. This has been a
> >common approach for unix apps.
> 
> yes, but running with SCHED_FIFO and calling mlockall has not been a
> common approach for unix apps. and because unix systems have made it
> difficult to grant applications permissions to use these capabilities
> with root permission somehow getting involved, adding these to a
> client-server design poses some very difficult questions.
I was really referring to the general process of starting as root and
then dropping privileges after doing something requiring root (eg
binding port < 1024) as something that is commonly done by unix apps.
The likes of SCHED_FIFO and mlock* are relatively new, and naturally
fell into the as-root-only bucket

ices itself does not use mlockall, in theory it could use mlock, but in
practise mlock hasn't been needed, as long as scheduling occurs.  There
are various internal limits set which can trigger easily if things are
not running well, and this may be something that has been seen by the
original poster. For those people who are really concerned about the
*risk* then realtime scheduling can be disabled in the xml. So far I
have no reports with this.
> ultimately, running anything SCHED_FIFO+mlockall+shm+fifo's opens up a
> world of possible DOS attacks on a machine, whether its run as root or
> not. my attitude is that until unix gives us better ways to manage
> this (and the LSM system in 2.6 is a reasonable start), its really not
> sensible to try to apply the conventional unix wisdom to this
> situation. or maybe it is ... remember while (1) { fork (); } as the
> guaranteed crash-inducer of many unix systems? SCHED_FIFO just
> replaces crash with "apparent lockup" caused by while (1) {
continue; }
In general I would think you're going to have this sort of risk with any
potential busy loop when realtime type priority scheduling is involved,
however it is implemented. 

karl.

>I can't really comment on jackd itself, as I haven't looked that
much
>into it.  If running jackd as root requires client apps to also run as
>root then that is a pretty bad issue. I would of thought that running
>jackd as a realtime process (whether root or not) would be an important
>consideration.
jackd (realtime) requires various resources which it shares with its
clients:

      realtime scheduling
      mlock-ability
      shared memory segments
      FIFOs (or Mach ports on OS X)

we consider it *more* of a security risk to allow jackd-as-root to
share these with non-root processes. YMMV.
>What I can say is that ices tries to acquire realtime scheduling if
>enabled (default is yes) which may or may not fail, but if root is used
what ices does is mostly irrelevant to JACK. the thread that handles
audio processing is created by JACK, and that thread does not inherit
any scheduling parameters from its parent. whether other ices thread
run SCHED_FIFO is besides the point, and probably should be discouraged.
>that user, and therefore _NOT_ run as root anymore. This has been a
>common approach for unix apps.
yes, but running with SCHED_FIFO and calling mlockall has not been a
common approach for unix apps. and because unix systems have made it
difficult to grant applications permissions to use these capabilities
with root permission somehow getting involved, adding these to a
client-server design poses some very difficult questions.

ultimately, running anything SCHED_FIFO+mlockall+shm+fifo's opens up a
world of possible DOS attacks on a machine, whether its run as root or
not. my attitude is that until unix gives us better ways to manage
this (and the LSM system in 2.6 is a reasonable start), its really not
sensible to try to apply the conventional unix wisdom to this
situation. or maybe it is ... remember while (1) { fork (); } as the
guaranteed crash-inducer of many unix systems? SCHED_FIFO just
replaces crash with "apparent lockup" caused by while (1) { continue;
}

--p