22 Aug
2003
22 Aug
'03
11:50 a.m.
Actually, I'd like to hear about why the kernel developers were shocked about our use
of capabilities. Could you expand on that?
Taybin
-------Original Message-------
From: Mark Knecht <mknecht(a)controlnet.com>
Sent: 08/22/03 09:55 AM
To: linux-audio-user(a)music.columbia.edu
Subject: RE: [linux-audio-user] Help neede with ardour
This is exactly what I have suggested yesterday and today. Gentoo does
this
other places, like with 3D acceleration. They provide ebuild that don't
work
until I compile my kernel to turn on certain things and edit my XF86config
file to enable features.
We'll see. I think we'll get there.
A while back some of the kernel developers were a bit shocked we were
using
capabilities this way, but that's another story! ;-)
- Mark
> >
> I will still enter a request, but it looks like this is considered
at
least
controversial by some at Gentoo.
Just including jackstart seems very sensible. The Debian package
includes jackstart and has instructions on how to patch the kernel for
capabilities. But if a user is running a stock kernel, jackstart
will not work, and one is forced to use jackd. This is absoluetly
okay, IMO.
The alternative would be to build a kernel-image, on that jackstart
depends, which just will not work out in the end. It's better to just
leave that in the users' responsibiliy. 
22 Aug
22 Aug
12:48 p.m.
New subject: [linux-audio-user] Help neede with ardour
Actually, I'd like to hear about why the kernel developers were
shocked about our use of capabilities. Could you expand on that?
Taybin
Taybin,
I wish I could, but thinking that it would likely be of little interest
to me I tuned out pretty quickly. There wasn't a lot of discussion as I
remember it. A number of people were using generic words like 'dangerous' or
'stupid', but frankly it didn't matter to me as this is the only game in
town. What choice do I have anyway?
There was no additional concern about actually running apps like Ardour
or Rosegarden as root vs. using capabilities. They hated that sort of answer
also. It was really that they didn't think any of this should run as root.
TO BE CLEAR - I have no issue with this one way or the other. I understand
I'm taking my chances. I'm OK with that. I will say that the other day I
quickly tried Rosegarden with Jack and as soon as I connected an audio track
in Rosegarden to a 'Jack Audio' stream the machine was locked up hard and
nothing but a hard reset would bring it back. THERE ARE RISKS. (My apologies
to Guillaume, Chris or Rich for bring that up here before signing up for
their lists again.)
If I had to venture a guess it was probably more that some 'intentionally
bad' application could be written to take advantage of a machine that had a
kernel patched for capabilities, and not specifically that jackstart itself
was a problem. I would suspect that a number of developers would not be
particularly concerned with this, but I'll make the observation that I
quickly counted more than 40 Jack applications on the web site this morning.
What percentage of those have actually been tested using a capabilities
based kernel, and what assurance does a user like me have that one of them
doesn't do an rm / intentionally or by mistake? As this list grows to 100 or
200 apps, how will I - as a user, not a developer - be protected against
something like this?
Please remember, that's just my guess and does not represent anyone's
true reasons.
Mark
2:36 p.m.
New subject: [linux-audio-user] Help neede with ardour
If I had to venture a guess it was probably more that
some 'intentionally
bad' application could be written to take advantage of a machine that had a
kernel patched for capabilities, and not specifically that jackstart itself
was a problem. I would suspect that a number of developers would not be
particularly concerned with this, but I'll make the observation that I
quickly counted more than 40 Jack applications on the web site this morning.
What percentage of those have actually been tested using a capabilities
based kernel, and what assurance does a user like me have that one of them
doesn't do an rm / intentionally or by mistake?
I think the only risk (that I know off) would be an application that
hangs the machine because there is an infinite loop or lockup in the
audio thread (which is the one that runs with SCHED_FIFO - realtime
schedulling). The capabilities granted by jackstart to jackd (thus to
the jack clients) do not allow the process access to arbitrary files.
Obviously that can happen if you are just running applications as root
and not using capabilities at all (all bets are off if you run as root).
Jack has a watchdog timer that supposedly would kill apps that do that.
It does not always work. When I was having problems with deadlocks in
2.4.20 (traced by Andrew Morton to a bug in the ext3 code) the internal
Jack watchdog process did not kill jack or the offending process. I used
another program (rt_monitor) to do that, and it was pretty effective in
reviving the machine after each lockup.
As this list grows to 100 or
200 apps, how will I - as a user, not a developer - be protected against
something like this?
Not that many choices (against badly behaving jack clients). Watchdog
timers that look for errant processes would be the first. But the _real_
protection should come from a better scheduler that takes that into
account in the kernel itself (I saw messages in a list, can't remember
which, and a patch for such a scheduler).
-- Fernando
3:40 p.m.
New subject: [linux-audio-user] Help neede with ardour
Fernando,
Thanks for the info. It's interesting.
In the text below, please remember I have no position on this. I'm just
asking some questions, not interrogating!
Mark
I think the only risk (that I know off) would be an application that
hangs the machine because there is an infinite loop or lockup in the
audio thread (which is the one that runs with SCHED_FIFO - realtime
schedulling). The capabilities granted by jackstart to jackd (thus to
the jack clients) do not allow the process access to arbitrary files.
Is this true for all applications running on a capabilities enabled kernel,
or just those that are granted capabilities by jackstart?
Is the concern clear? Could a particularly nasty person create a program
replace some file used by jackstart of a Jackified application, that could
open up the permissions you've granted?
On this kernel could that nasty person create a program that exploits these
capabilities in ways beyond what you are granting?
I think this is the general concern, as I have understood it.
Obviously that can happen if you are just running applications as root
and not using capabilities at all (all bets are off if you run as root).
Certainly
Maybe it's of no concern. I don't know. I think one of the advertised
advantages of Linux is its security. However, one of the weaknesses is that
people download source, of which they have no real knowledge, build and
install as root, and then try out. PlanetCCRMA really reduces this weakness
as we get precompiled binaries with folks like you to help protect us.
However, if some nasty person out there wants to exploit this potential
weakness then they could cause problems for people getting source from the
net, and I think the 'capabilities enabled kernel' *may* make these
weaknesses greater??
- Mark
4:53 p.m.
New subject: [linux-audio-user] Help neede with ardour
In the text below, please remember I have no position
on this. I'm just
asking some questions, not interrogating!
Could you please turn OFF that SPOTLIGHT!! :-)
I think the
only risk (that I know off) would be an application that
hangs the machine because there is an infinite loop or lockup in the
audio thread (which is the one that runs with SCHED_FIFO - realtime
schedulling). The capabilities granted by jackstart to jackd (thus to
the jack clients) do not allow the process access to arbitrary files.
Is this true for all applications running on a capabilities enabled kernel,
or just those that are granted capabilities by jackstart? Is the concern clear? Could a particularly nasty
person create a program
replace some file used by jackstart of a Jackified application, that could
open up the permissions you've granted?
Meaning grant more capabilities than just "allow you to switch into
SCHED_FIFO"? Yes, of course. A "hacked" jackstart/jack would be able to
do that. You could give jack clients any capabilities you wanted. But of
course any program that is hacked can be made into an evil program :-) A
hacked jack _client_ would not be able to receive any more than what
jackstart/jackd gives.
On this kernel could that nasty person create a
program that exploits these
capabilities in ways beyond what you are granting?
Meaning a clever programmer just creating a jack client? No, I don't
think so (but what do I know?). As long as jack is not changed then it
will just give a given set of capabilities, a client can only receive or
get what is given.
But jackstart does not have a monopoly on using capabilities. Any
program can use them in a capabilities enabled kernel. But to "exploit"
capabilities you have to initially be root (jackstart is suid root for
that reason). But, if you are root somehow and want to do nasty things,
you don't really need capabilities at all.
Maybe it's of no concern. I don't know. I
think one of the advertised
advantages of Linux is its security. However, one of the weaknesses is that
people download source, of which they have no real knowledge, build and
install as root, and then try out.
Yup. Any time you do something as root you are vulnerable.
PlanetCCRMA really reduces this weakness
as we get precompiled binaries with folks like you to help protect us.
Yes and no. While I take care with what I build there are no guarantees.
In that sense I'm not that different from a "regular" user, obviously it
would be impossible for me to security audit all software...
However, if some nasty person out there wants to
exploit this potential
weakness then they could cause problems for people getting source from the
net, and I think the 'capabilities enabled kernel' *may* make these
weaknesses greater??
Not really. If some nasty person wants to create problems it does not
need to use capabilities. The very fact that normally users build
software as root is more than enough (ie: create a software project with
a fancy name, make users install it as root and in the process create a
back door for latter hacking). Ugly and simple.
-- Fernando
8161
days inactive
8161
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Fernando Pablo Lopez-Lezcano -
Mark Knecht -
Taybin Rutkin