[PlanetCCRMA] Fwd: jack2

[Niels Mayer]

On Sun, Apr 18, 2010 at 7:29 PM, Fernando Lopez-Lezcano <
nando at ccrma.stanford.edu> wrote:

>  described here:
> http://old.nabble.com/help-w--qjackctl-locks-up-X-GUI-(perhaps-caused-by-dbus-or-kernel-2.6.32.11-99.fc12.x86_64)-to28221239.html)
>
> I don't think we know why that was happening.
>

I was hypothesizing that any other application which made request for
rtprio, negative nice, or memlock, but might be granted lower or higher
priority than jack, may end up getting exactly the same priority levels as
jackd; this could mean that two application, running by design at different
priority levels, wouldn't deadlock -- but run at the same priority levels,
they have a better chance of deadlocking. So for example if this new jackd
was trying to signal via dbus to turn off pulseaudio, and pulseaudio itself
was now attempting to run, except that I've turned off pulseaudio on my
workstations, and removed the packages. But nonetheless, something
(libgnome?) still is creating ~/.pulse and ~/.pulse-cookie and perhaps
deadlocking in the process....

Alternately, this could be an instance of "priority inversion" made famous
by the mars pathfinder
http://research.microsoft.com/en-us/um/people/mbj/Mars_Pathfinder/Authoritative_Account.html
but
also plaguing more prosaic hardware such as
http://reviews.cnet.com/digital-video-recorders-dvrs/directv-hr20-directv-plus/4852-6474_7-32065196.html?tag=psum
(deadlock
whackamole on hardware with four simultaneous HD PVRs, that could barely
record or watch two channels w/o crashing).

One difference between the workstation that suffered from the lockup
problem, and one that didn't -- is the following entry in limits.conf (from
F12's Jack, but didn't get removed by CCRMA's jack?) found on the
problematic computer:

## Automatically appended by jack-audio-connection-kit

@jackuser - rtprio 20

@jackuser - memlock 4194304

## Automatically appended by jack-audio-connection-kit

@pulse-rt - rtprio 20

@pulse-rt - nice -20

## Automatically appended by the Planet CCRMA jack-audio-connection-kit

* - rtprio 99

* - memlock 4194304

* - nice -10


In other words, the jack options at the end would potentially "override" the
settings above for 'pulse-rt' and 'jackuser' -- this seems problematic. I've
removed the additional non-CCRMA jack-audio-connection-kit settings from
this limits.conf, and also changed the wildcards to @jackuser -- we'll see
how things go now...

........

 This is not related to applications but to users. It means any user can

run apps with realtime priorities.


It's related to applications in that most applications don't request
realtime priority, negative nice levels, etc. However, with the settings
from limits.conf, any application, including a rogue application that might
otherwise be well behaved because it wasn't granted permission to run at
elevated priv levels -- would now get them. Furthermore if some other app
had settings in limits.conf with lesser priority levels (say nice of -1, and
less rtprio), the wildcard matching for all apps && all users could end up
giving that app the potential of running at much higher priorities.

Worst, services/deamons that normally run safely due to their minimal set of
privileges and a security design principle towards
http://en.wikipedia.org/wiki/Privilege_separation would now all have the
privileges, literally, combined. Daemon processes running as 'nobody' or as
separate low-priv users with a specific part of the filesystem they can
read/write, will now be able to attain unreasonable levels of
priority. This means that one could lockup such a workstation remotely
simply by activating a network service -- even if only for the service to
deny access -- do it often enough w/ a highly privileged process and you can
lockup a computer. It sidesteps the whole notion of "dropping root" in a
network service (e.g. sshd):

Many network service daemons have to do a specific privileged operation such
> as open a raw socket or an Internet socket in the well known ports range.
> Administrative utilities can require particular privileges at runtime as
> well. Such software tends to separate privileges by revoking them completely
> after the critical section is done, and change the user it runs under to
> some unprivileged account after so doing. This action is known as dropping
> root under Unix-like operating systems. The unprivileged part is usually run
> under the "nobody" user or an equivalent separate user account.


Now normally, if this was a simple denial-of-service -- no biggie, just
reboot. But with the current settings, even a simple "rogue" script could
trigger a far worse DOS -- eg. jamming a network, router, website, etc. This
is especially true because every single workstation that installed jack
could become a host for a distributed DOS attack.

Normally, installing fedora packages doesn't automatically degrade security
-- you have to configure it, and/or add servces to chkconfig in order to
activate. In this case, a user who blindly installs any package from CCRMA
will get jackd's limits.conf settings as a dependency. Due to the security
concerns, I assume/hope those settings will not be in the F12 version of
jack2.

Given all that fear, uncertainty and doubt, combined with my general level
of weeniedom, I changed my limits.conf to:

## Automatically appended by the Planet CCRMA jack-audio-connection-kit

## NPM changed '*' to @jackuser to limi

@jackuser - rtprio 99

@jackuser - memlock 4194304

@jackuser - nice -10


-- Niels
http://nielsmayer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100419/c904c372/attachment.html