16 Nov
2003
16 Nov
'03
10:19 a.m.
"Jack O'Quin":
I've been thinking about ways to use this feature to improve and
simplify the current security situation for Linux audio. No
conclusions, but here are some thoughts for discussion:
(1) There should a simple way for the sysadmin to reliably disallow
realtime privileges. One way to allow (or prevent) access to
realtime privileges for any program is via a sysctl global variable.
Of course, loading the kernel extension is a privileged operation,
anyway. But, I prefer some positive means of blocking it.
(2) Using sysctl, set a group id (like `audio') for which realtime
privileges are automatically granted. Then, we could just install
realtime apps with `setgid audio'. This seems much better than
opening things up to *any* application. And, audio applications
would not need root privileges any more. This would be a rather big
improvement over the current jackstart/jackd situation.
(3) We could also define a default realtime group (gid 0 maybe),
since `audio' probably does not exist on many distributions. IIUC,
this is originally a Debian idea. I don't know how widely it has
been adopted. I like it and think it should become a universal
Linux convention, allowing access to the sound card as well as
realtime privileges.
What about this one:
(4) Let the user that is currently physical logged in to the machine
get realtime privileges.
--
16 Nov
16 Nov
12:03 p.m.
> I've been thinking about ways to use this
feature to improve and
> simplify the current security situation for Linux audio. No
> conclusions, but here are some thoughts for discussion:
>
> (1) There should a simple way for the sysadmin to reliably disallow
[ ..
]
> (2) Using sysctl, set a group id (like
`audio') for which realtime
[ ... ]
> (3) We could also define a default realtime
group (gid 0 maybe),
What about this one:
(4) Let the user that is currently physical logged in to the machine
get realtime privileges.
i'd be interested to hear from fernando about this kind of thing. many
of us on LAD work on what are to all effects and purposes single user
machines. i'd like to hear how policies like 1-4 above, or others,
appear in the context of an academic "shared resource" environment.
--p
ps. this is the kind of thing that can really distinguish *nix from
other systems. i've heard from at least academic music department
about the problems they've faced since being forced to switch to
windows.
17 Nov
17 Nov
1:18 a.m.
On Sun, 2003-11-16 at 08:02, Paul Davis wrote:
["academic" is probably irrelevant, a commercial studio should see the
advantages of the security model if educated]
As far as I understand these are the current options:
a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl
"b" is better than "a" (more general purpose)
is "b" riskier than "a"?
you could say yes: all programs can use realtime caps
you could say no: "a" enables additional unneeded and dangerous stuff
"c" is the same as "b" (from the point of view of a user or sysadmin)
"c" has more long term potential in the sense that it uses a recognized
kernel interface to security (but only on 2.6, right?)
I would be happy with "b" right now. A group would not be important in
_my_ setup, all my users are "audio users", all users can hang the
machine (I have too much to do to try to start categorizing users :-)
I would say (as in Kjetil's patch):
echo "0">/proc/sys/kernel/setschedandmlock
--> normal behavior
echo "1">/proc/sys/kernel/setschedandmlock
--> access to mlock and SCHED_FIFO and:
echo "xx">/proc/sys/kernel/setschedandmlockgroup
--> only users in group "xx" can access privileges
default for "xx" would be "0" which means everybody
as to (4), it could be useful but I doubt you can easily determine from
inside the kernel that a user is "local" (just guessing).
> I've
been thinking about ways to use this feature to improve and
> simplify the current security situation for Linux audio. No
> conclusions, but here are some thoughts for discussion:
>
> (1) There should a simple way for the sysadmin to reliably disallow
[ ..
]
> (2) Using sysctl, set a group id (like
`audio') for which realtime
[ ... ]
> (3) We could also define a default realtime
group (gid 0 maybe),
What about this one:
(4) Let the user that is currently physical logged in to the machine
get realtime privileges.
i'd be interested to hear from fernando about this kind of thing. many
of us on LAD work on what are to all effects and purposes single user
machines. i'd like to hear how policies like 1-4 above, or others,
appear in the context of an academic "shared resource" environment. ps. this is the kind of thing that can really
distinguish *nix from
other systems. i've heard from at least academic music department
about the problems they've faced since being forced to switch to
windows.
I would not want to be in that position...
-- Fernando
12:18 p.m.
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
As far as I understand these are the current options:
a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl
"b" is better than "a" (more general purpose)
is "b" riskier than "a"?
you could say yes: all programs can use realtime caps
you could say no: "a" enables additional unneeded and dangerous stuff
"c" is the same as "b" (from the point of view of a user or
sysadmin)
"c" has more long term potential in the sense that it uses a recognized
kernel interface to security (but only on 2.6, right?)
Right. There actually is a backport of the security modules patch to
2.4 on the NSA site for SELinux. But, it is rather large and I doubt
many people would want to apply it.
I would be happy with "b" right now. A group
would not be important in
_my_ setup, all my users are "audio users", all users can hang the
machine (I have too much to do to try to start categorizing users :-)
I would say (as in Kjetil's patch):
echo "0">/proc/sys/kernel/setschedandmlock
--> normal behavior
I suggest picking a clearer name, like /proc/sys/kernel/realtime.
echo
"1">/proc/sys/kernel/setschedandmlock
--> access to mlock and SCHED_FIFO and:
echo "xx">/proc/sys/kernel/setschedandmlockgroup
--> only users in group "xx" can access privileges
default for "xx" would be "0" which means everybody
Here, I suggest something like /proc/sys/kernel/rtgroup.
Also, 0 is a valid group ID, `root', which might be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
So, I'm thinking we could provide these sysctl interfaces on both 2.4
and 2.6, though via different mechanisms...
(1) `kernel/realtime' works as in Kjetil's patch
(2) `kernel/rtgroup' further restricts access
Kjetil's patch could be expanded to include (2), providing consistent
interfaces across kernel versions. Assuming that's agreeable with
him, of course. :-)
I might give it a try myself, just to see if this really works as I
imagine.
--
joq
7:44 p.m.
On Mon, 2003-11-17 at 08:17, Jack O'Quin wrote:
I agree, sounds better. It does not say what it does as the original
proposal, but maybe we will need something else in the future that could
be done through this as well.
Maybe "realtimegroup"? I kind of like the same "root" for both
options,
it groups them together.
Right. There actually is a backport of the security
modules patch to
2.4 on the NSA site for SELinux. But, it is rather large and I doubt
many people would want to apply it.
I would say that for 2.4 a simple patch would be easier. I'm a bit tired
of hard to (re)apply kernel patches :-)
I would be
happy with "b" right now. A group would not be important in
_my_ setup, all my users are "audio users", all users can hang the
machine (I have too much to do to try to start categorizing users :-)
I would say (as in Kjetil's patch):
echo "0">/proc/sys/kernel/setschedandmlock
--> normal behavior
I suggest picking a clearer name, like /proc/sys/kernel/realtime. echo
"1">/proc/sys/kernel/setschedandmlock
--> access to mlock and SCHED_FIFO and:
echo "xx">/proc/sys/kernel/setschedandmlockgroup
--> only users in group "xx" can access privileges
default for "xx" would be "0" which means everybody
Here, I suggest something like /proc/sys/kernel/rtgroup. Also, 0 is a valid group ID, `root', which might
be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
Yes, probably "nogroup" is the best option. I think it is "nobody" in
my
system - so we cannot rely on the same name either... yuck...
So, I'm thinking we could provide these sysctl
interfaces on both 2.4
and 2.6, though via different mechanisms...
(1) `kernel/realtime' works as in Kjetil's patch
(2) `kernel/rtgroup' further restricts access
Kjetil's patch could be expanded to include (2), providing consistent
interfaces across kernel versions. Assuming that's agreeable with
him, of course. :-)
I hope so.......
Looks good to me.
-- Fernando
11:11 p.m.
Fernando Pablo Lopez-Lezcano writes:
I agree, sounds better. It does not say what it does as the original
++votes
Maybe "realtimegroup"? I kind of like the same "root" for both
options,
it groups them together.
++votes
i think it would be safer to use 0, which means root (and is kinda
senseless) as default. granting realtime privileges to everybody is
exactly what we don't want... and it's likely to do that by accident
when having this as a default.
or did i miss the meaning of "nogroup"? i ever thought that this is
the group for users which are granted really NOTHING...
martin
I would say (as in Kjetil's patch):
echo "0">/proc/sys/kernel/setschedandmlock
--> normal behavior
I suggest picking a clearer name, like /proc/sys/kernel/realtime. echo
"1">/proc/sys/kernel/setschedandmlock
--> access to mlock and SCHED_FIFO and:
echo "xx">/proc/sys/kernel/setschedandmlockgroup
--> only users in group "xx" can access privileges
default for "xx" would be "0" which means everybody
Here, I suggest something like /proc/sys/kernel/rtgroup. Also, 0 is a
valid group ID, `root', which might be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
Yes, probably "nogroup" is the best option. I think it is "nobody" in
my
system - so we cannot rely on the same name either... yuck...
18 Nov
18 Nov
midnight
martin rumori <ptiger(a)gmx.de> writes:
i think it would be safer to use 0, which means root (and is kinda
senseless) as default. granting realtime privileges to everybody is
exactly what we don't want... and it's likely to do that by accident
when having this as a default.
or did i miss the meaning of "nogroup"? i ever thought that this is
the group for users which are granted really NOTHING...
Nando's original suggestion was to use 0 for allowing access to
everybody. I felt that group `root' (gid 0) was a useful value, so I
suggested some different code point possibilities for "everybody". I
actually prefer -1, since that is not a valid group number.
But, I also mentioned `nogroup' (65534) as a possibility (`nobody' on
some systems). Some daemons actually run with this group to avoid
gaining access to real groups. So, I don't think it a very good idea.
I agree that 0 should be the default. It exists on every system and
is rather restrictive, so people won't accidentally grant more access
than they intended.
To summarize, my proposal is:
sysctl -w kernel/realtime=0 # disable realtime privileges
sysctl -w kernel/realtime=1 # enable realtime privileges
# for `root' group
sysctl -w kernel/realtime=1 # enable realtime privileges
sysctl -w kernel/realtimegroup=-1 # for every process
sysctl -w kernel/realtime=1 # enable realtime privileges
sysctl -w kernel/realtimegroup=29 # for `audio' group
Only root can write these variables. If possible, let's agree on a
standard gid to use for group `realtime', there isn't one now.
--
joq
Also, 0 is a valid group ID, `root', which might
be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
Yes, probably "nogroup" is the best option. I think it is "nobody" in
my
system - so we cannot rely on the same name either... yuck...
3:21 p.m.
On Mon, 2003-11-17 at 19:59, Jack O'Quin wrote:
To summarize, my proposal is:
sysctl -w kernel/realtime=0 # disable realtime privileges
sysctl -w kernel/realtime=1 # enable realtime privileges
# for `root' group
sysctl -w kernel/realtime=1 # enable realtime privileges
sysctl -w kernel/realtimegroup=-1 # for every process
sysctl -w kernel/realtime=1 # enable realtime privileges
sysctl -w kernel/realtimegroup=29 # for `audio' group
Only root can write these variables. If possible, let's agree on a
standard gid to use for group `realtime', there isn't one now.
Sounds good to me...
Here's a list of uids/gids as used in RedHat (courtesy of Matthias):
http://freshrpms.net/packages/res/uidgid.html
I seem to remember having read somewhere of an initiative to standarize
all these numbers, can't remember where or when.
-- Fernando
11:36 p.m.
On Mon, Nov 17, 2003 at 09:59:11PM -0600, Jack O'Quin wrote:
martin rumori <ptiger(a)gmx.de> writes:
> senseless) as default. granting realtime privileges to everybody is
> exactly what we don't want... and it's likely to do that by accident
I agree that 0 should be the default. It exists on
every system and
is rather restrictive, so people won't accidentally grant more access
To summarize, my proposal is:
snip
Only root can write these variables. If possible,
let's agree on a
standard gid to use for group `realtime', there isn't one now.
looks like a clean solution.
cheers, martin
17 Nov
17 Nov
4:20 p.m.
On Monday 17 November 2003 06.17, Fernando Pablo Lopez-Lezcano wrote:
On Sun, 2003-11-16 at 08:02, Paul Davis wrote:
i'd be interested to hear from fernando about this kind of thing. many
of us on LAD work on what are to all effects and purposes single user
machines. i'd like to hear how policies like 1-4 above, or others,
appear in the context of an academic "shared resource" environment.
["academic" is probably irrelevant, a commercial studio should see the
advantages of the security model if educated]
As far as I understand these are the current options:
a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl
What about:
d) redefining sched_setscheduler using LD_PRELOAD with running rt_monitor
+ No change in kernel.
+ No change in application code. (Like capabilities - do not check uid,
but it can fake uids too!)
+ Can use whatever kernel provides
+ Only requires the rt_monitor to be started by root - can be done by init
+ Protects the system from overuse (and lockups) due to bugs in code.
- Can not provide mlockall since it has no pid parameter - the monitor
can't do it for another process. (I would say that it is unlikely that pages
used in a tight audio loop would be thrown out - big buffers might...
Add additional page reads?)
/RogerL
--
Roger Larsson
Skellefteå
Sweden
>
I've been thinking about ways to use this feature to improve and
> simplify the current security situation for Linux audio. No
> conclusions, but here are some thoughts for discussion:
>
> (1) There should a simple way for the sysadmin to reliably disallow
[ .. ]
> (2) Using sysctl, set a group id (like
`audio') for which realtime
[ ... ]
(3) We
could also define a default realtime group (gid 0 maybe),
What about this one:
(4) Let the user that is currently physical logged in to the machine
get realtime privileges.
7:48 p.m.
i'd be interested to hear from fernando about this
kind of thing. many
of us on LAD work on what are to all effects and purposes single user
machines. i'd like to hear how policies like 1-4 above, or others,
appear in the context of an academic "shared resource" environment.
["academic" is probably irrelevant, a commercial studio should see the
advantages of the security model if educated]
As far as I understand these are the current options:
a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl + No change in kernel.
+ No change in application code. (Like capabilities - do not check uid,
but it can fake uids too!)
+ Can use whatever kernel provides
+ Only requires the rt_monitor to be started by root - can be done by init
Not a problem so far (but I don't like to use LD_PRELOAD at all, just a
personal preference).
+ Protects the system from overuse (and lockups) due
to bugs in code.
Very good.
- Can not provide mlockall since it has no pid
parameter - the monitor
can't do it for another process. (I would say that it is unlikely that pages
used in a tight audio loop would be thrown out - big buffers might...
Add additional page reads?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory......
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
-- Fernando
9:42 p.m.
Fernando Pablo Lopez-Lezcano <nando(a)ccrma.stanford.edu> writes:
Agreed. IMHO, mlock() is mandatory, certainly for JACK applications.
The big difference between realtime and most other kinds of
performance work is that it focuses on tuning the "worst case", not
the average. Paging works fine on average, but in the worst case your
recording session gets blown.
Otherwise, a good solution. Perhaps adequate for some applications.
- Can not
provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional page reads?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory...... BUT, I think a userspace daemon that starts at boot
time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes it would. I've been using an earlier version of Roger's
rt_monitor quite a lot lately while chasing JACK bugs. It works very
well and has never caused any noticeable trouble on my system.
--
joq
18 Nov
18 Nov
3:22 a.m.
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano
<nando(a)ccrma.stanford.edu> writes:
Agreed. IMHO, mlock() is mandatory, certainly for JACK applications.
Problem is - why doesn't most distributions even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional)
So with any scheme that opens up these holes you have to deliver a way
to protect from the downsides.
My monitor protects from CPU overuse, but what about memory?
How to protect from an application that mlockall(MCL_FUTURE) and
has a memory leak?
One important thing to remember - if you like to get broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
- Can not
provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional page reads?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory......
The big difference between realtime and most other kinds of
performance work is that it focuses on tuning the "worst case", not
the average. Paging works fine on average, but in the worst case your
recording session gets blown.
SCHED_FIFO does not make ANY guarantees on "worst case"!
Otherwise, a good solution. Perhaps adequate for some applications.
But at the same time SCHED_FIFO is adequate for most applications.
See my point? :-)
/RogerL
--
Roger Larsson
Skellefteå
Sweden
3:48 p.m.
On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
Correct. We do have xruns every once in a while, it depends a lot on the
hardware and how the system is tuned. If we get real serious, from the
point of view of "worst case", linux is the wrong tool to do realtime
audio processing. Something like QNX would be better (a _real_ realtime
operating system).
I see your point. There is no clearly marked dividing line in either
case. For a certain very high latency requirement SCHED_OTHER, in the
average, is just fine. For the latency expectations of most people in
this list SCHED_FIFO is a good solution (if the kernel is patched for
low latency operation - otherwise it does not work either). If you
really go down in latency, SCHED_FIFO is no longer good enough. This
part at least is clear to me (we _need_ SCHED_FIFO), but equally clear
is the fact that it will not _always_ work (100% of the time).
So the question about mlockall would be, is it something akin to
SCHED_OTHER? (ie: with it the whole thing is unusable?). Or is it like
SCHED_FIFO? (ie: not 100% perfect but we really need to have it?).
My feeling is that we need it, but I don't have experimental data to
back it up.
Any one out there doing experiments with this? Something like: start a
critical audio app with and without mlockall, subject the machine to
high memory loads to force paging (ie: start a lot of applications), see
what happens.
Of course there does not have to be just _one_ answer to the question!
Let's implement both and let the user choose according to his/her/its
needs :-)
-- Fernando
On Tuesday 18 November 2003 02.41, Jack O'Quin
wrote:
That's one reason why you won't see this done on any general purpose
distribution. Another reason: most (all?) mainstream distributions do
not cater to the "pro audio" users that need very reliable and very low
latency operation. Yet another: it is difficult :-)
Fernando Pablo Lopez-Lezcano
<nando(a)ccrma.stanford.edu> writes:
Agreed. IMHO, mlock() is mandatory, certainly for JACK applications.
Problem is - why doesn't most distributions even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional) - Can not
provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional page reads?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory...... So with any scheme that opens up these holes you have
to deliver a way
to protect from the downsides.
Or not. Sometimes you have to learn to live with them...
My monitor protects from CPU overuse, but what about
memory?
How to protect from an application that mlockall(MCL_FUTURE) and
has a memory leak?
Good point. Probably you can't.... :-(
One important thing to remember - if you like to get
broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
I don't (personally) want or need at this point in time for the solution
to have "broad acceptance", although that would be real nice. I want
something that enables me to run applications with real time priority
and memory lock as a normal user. So far the options that target both
aspects (scheduler and memory lockdown) involve a kernel patch.
The big
difference between realtime and most other kinds of
performance work is that it focuses on tuning the "worst case", not
the average. Paging works fine on average, but in the worst case your
recording session gets blown.
SCHED_FIFO does not make ANY guarantees on "worst case"! Otherwise, a
good solution. Perhaps adequate for some applications.
But at the same time SCHED_FIFO is adequate for most applications.
See my point? :-)
4:03 p.m.
One important
thing to remember - if you like to get broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
I don't (personally) want or need at this point in time for the solution
to have "broad acceptance", although that would be real nice. I want
something that enables me to run applications with real time priority
and memory lock as a normal user. So far the options that target both
aspects (scheduler and memory lockdown) involve a kernel patch. Of course there does not have to be just _one_ answer
to the question!
Let's implement both and let the user choose according to his/her/its
needs :-)
its a few lines of code to be commented in JACK. somebody try it out
(its in jackd/engine.c and libjack/client.c)
--p
6:24 p.m.
On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for
broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
Wouldn't it, just maybe, be acceptable to the kernel people if capabilities
could be turned on by some parameter on the kernel command line (e.g.
capabilities=on)?
This would make capabilities disabled by default, but gives a way to enable
them that does not require a kernel patch and rebuild...
Melanie
6:54 p.m.
Melanie <melanie(a)t-data.com> writes:
Wouldn't it, just maybe, be acceptable to the
kernel people if
capabilities could be turned on by some parameter on the kernel
command line (e.g. capabilities=on)?
We could ask. But, I suspect they will feel that they have adequately
solved this problem in 2.6 by providing the pluggable security module
infrastructure. This was doubtless motivated by a strong desire to
*avoid* such discussions with an endless procession of people like us
with "special security needs".
From that perspective, security modules look like an
excellent
solution.
This would make capabilities disabled by default, but
gives a way to
enable them that does not require a kernel patch and rebuild...
That would be nice, but I don't expect to see it backported to 2.4.
--
joq
7:01 p.m.
On 2003.11.18 21:02 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with complete confidence that even if you do not use the cmdline arg
that the presence of capabilities support does not pose a security issue.
by contrast, kjetil's patch has very deterministic and very local
effects, and when its off, we know its off.
i'm with fernando on this. we are not looking
for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
Wouldn't it, just maybe, be acceptable to the kernel people if capabilities
could be turned on by some parameter on the kernel command line (e.g.
capabilities=on)?
This would make capabilities disabled by default, but gives a way to enable
them that does not require a kernel patch and rebuild...
7:29 p.m.
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into
the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with complete confidence that even if you do not use the cmdline arg
that the presence of capabilities support does not pose a security issue.
Well, capabilities are _always_ compiled into the kernel. The only thing
changed to enable them are two static data values, specifically the ones
used to start init with. This happens in one place and one place only.
Instead of #defines, these could be globals. Of course they would need to
be set before init is run, so a kernel command line parameter is the only
place it can be done easily.
Nothing changes thoughout the kernel but these two data values...
Melanie
7:53 p.m.
Melanie <melanie(a)t-data.com> writes:
On 2003.11.19 00:00 Paul Davis wrote:
This is true. It would be easy to change and only affects two values.
But, if you consider the situation of servers running in a colocate
environment, many sysadmins would want to prevent even people with
physical access to the machine from being able to change their
security model so drastically.
--
joq
i don't think they want them even compiled
into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with complete confidence that even if you do not use the cmdline arg
that the presence of capabilities support does not pose a security issue.
Well, capabilities are _always_ compiled into the kernel. The only
thing changed to enable them are two static data values, specifically
the ones used to start init with. This happens in one place and one
place only. Instead of #defines, these could be globals. Of course
they would need to be set before init is run, so a kernel command line
parameter is the only place it can be done easily.
8:41 p.m.
Roger Larsson <roger.larsson(a)norran.net> writes:
I didn't mention "guarantees", I spoke of "focusing on tuning".
Big
difference.
SCHED_FIFO is a blunt instrument. By itself, not adequate for much of
anything. Used in conjunction with carefully tuned hardware and
software, a low-latency kernel, and a known set of well-written audio
applications, rather decent realtime performance can be achieved with
only commodity hardware and free software. That's not bad.
No, I don't.
--
joq
Problem is - why doesn't most distributions even
ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional)
That seems logical, but AFAICT the actual reason is because of a
security hole introduced by CAP_SETPCAP (which was not part of the
original POSIX draft spec). Before this screwup was detected, kernels
shipped with capabilities enabled.
If an attacker manages to subvert one of the system daemons with a
buffer overflow (sendmail is a frequent target), it can use
CAP_SETPCAP to deny capabilities to other system services that need
them to perform their jobs, including monitoring system security.
So with any scheme that opens up these holes you have
to deliver a way
to protect from the downsides.
Clearly this is desirable. But, for many audio workstations it is
*not* mandatory.
My monitor protects from CPU overuse, but what about
memory?
How to protect from an application that mlockall(MCL_FUTURE) and
has a memory leak?
If you fail to solve this problem, then we end up back where we are
right now: patching kernels or running untrusted audio applications as
root. This solution is much worse than the problem you were trying to
solve.
One important thing to remember - if you like to get
broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
But, only if it works. It would really be great if you *could* come
up with a solution.
The big
difference between realtime and most other kinds of
performance work is that it focuses on tuning the "worst case", not
the average. Paging works fine on average, but in the worst case your
recording session gets blown.
SCHED_FIFO does not make ANY guarantees on "worst case"! Otherwise, a
good solution. Perhaps adequate for some applications.
But at the same time SCHED_FIFO is adequate for most applications.
See my point? :-)
19 Nov
19 Nov
3:58 a.m.
On Wednesday 19 November 2003 01.40, Jack O'Quin wrote:
But on those audio workstations you have NO problem to make
wrappers suid root.
* The "audio workstation" case can always be handled.
* The problematic case is "common desktop" where users get a much worse
experience than they should - and it might scare people off.
I have an idea!
rt_monitor is running mlockall and I avoided
* dynamic memory allocation
* system calls
- If I split the function into server and monitor (two threads) it would be
even better.
So rt_monitor itself should never get stuck requesting more memory, nor get
stuck in a system call getting stuck on another process requesting more
memory.
But it could monitor the RT processes memory usage and kill those crossing
the line.
Will try it tonight...
/RogerL
--
Roger Larsson
Skellefteå
Sweden
Roger Larsson <roger.larsson(a)norran.net>
writes:
Yes, lets take a specific example arts (KDE audio) and artswrapper.
Artswrapper should be suid root to give arts the desired SCHED_FIFO,
that is close to the full function of artswrapper - but still it is not
shipped suid root...
Problem is - why doesn't most distributions
even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional)
That seems logical, but AFAICT the actual reason is because of a
security hole introduced by CAP_SETPCAP (which was not part of the
original POSIX draft spec). Before this screwup was detected, kernels
shipped with capabilities enabled.
If an attacker manages to subvert one of the system daemons with a
buffer overflow (sendmail is a frequent target), it can use
CAP_SETPCAP to deny capabilities to other system services that need
them to perform their jobs, including monitoring system security. So with any scheme that opens up these holes you
have to deliver a way
to protect from the downsides.
Clearly this is desirable. But, for many audio workstations it is
*not* mandatory. My monitor protects from CPU overuse, but what
about memory?
How to protect from an application that mlockall(MCL_FUTURE) and
has a memory leak?
If you fail to solve this problem, then we end up back where we are
right now: patching kernels or running untrusted audio applications as
root. This solution is much worse than the problem you were trying to
solve.
10:54 a.m.
Roger Larsson <roger.larsson(a)norran.net> writes:
But on those audio workstations you have NO problem to
make
wrappers suid root.
* The "audio workstation" case can always be handled.
* The problematic case is "common desktop" where users get a much worse
experience than they should - and it might scare people off.
OK, now I see your point. We were working on different problems. I
mostly agree, though I much prefer making audio apps setgid `realtime'
and not setuid `root'.
I have an idea!
rt_monitor is running mlockall and I avoided
* dynamic memory allocation
* system calls
- If I split the function into server and monitor (two threads) it
would be even better.
So rt_monitor itself should never get stuck requesting more memory, nor get
stuck in a system call getting stuck on another process requesting more
memory.
Sounds like a good idea.
--
joq
20 Nov
20 Nov
8:27 p.m.
New subject: [CODE] rts with memory protection (Was: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24)
On Wednesday 19 November 2003 15.53, Jack O'Quin wrote:
Roger Larsson <roger.larsson(a)norran.net>
writes:
Something like this... some build and test bugs corrected.
/RogerL
--
Roger Larsson
Skellefteå
Sweden
I have an idea!
rt_monitor is running mlockall and I avoided
* dynamic memory allocation
* system calls
- If I split the function into server and monitor (two threads) it
would be even better.
So rt_monitor itself should never get stuck requesting more memory, nor
get stuck in a system call getting stuck on another process requesting
more memory.
Sounds like a good idea.
16 Nov
16 Nov
8:53 p.m.
Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> writes:
What about this one:
(4) Let the user that is currently physical logged in to the machine
get realtime privileges.
Good idea.
I don't know enough about the 2.6 security model to say how one might
go about implementing that.
In some ways this reminds me of the "Secure Attention Key" specified
by the DoD Orange Book for secure systems. The Linux kernel has an
SAK of sorts (see Documentation/SAK.txt in the kernel sources). This
rather cumbersome idea is intended to defeat Trojan horse attacks such
as putting up a fake login screen to steal passwords. The SAK kills
any process attached to the terminal (/dev/console in this case), and
then starts a known trusted application to which the user must
authenticate himself.
This seems overkill for implementing your idea, but something along
those lines would probably work, I suppose. I presume that the
SELinux people have come up with solutions for these problems that
work within the 2.6 security module scheme.
It does seem difficult within the context of X11 to prove that a user
is actually local to the machine. Some people may want to cluster
audio systems on a LAN somehow, so that restriction may not always be
appropriate.
Careful system administration can probably ensure that only a small
group of users are authorized to login. One of the things I like
about the `audio' group approach is that it is easy to administer and
simple to verify who has access to those privileges.
--
joq
9:58 p.m.
Kjetil Svalastog Matheussen
<k.s.matheussen(a)notam02.no> writes:
> (4) Let the user that is currently physical logged in to the machine
> get realtime privileges.
Jack O'Quin writes:
It does seem difficult within the context of X11 to
prove that a user
is actually local to the machine. Some people may want to cluster
audio systems on a LAN somehow, so that restriction may not always be
agree. for most of the graphical applications like ardour, the
assumption "local user <-> realtime user" might be correct. but in
general i don't see the advantage over the group solution. their
might be local users on a machine which should not have realtime
privileges.
Careful system administration can probably ensure that
only a small
group of users are authorized to login. One of the things I like
about the `audio' group approach is that it is easy to administer and
simple to verify who has access to those privileges.
i think, that's a clean solution. to be able to distinguish between
realtime- and non-realtime-audio users, i'd propose to use a separate
group (e.g. 'rtaudio'), so
(5) introduce a group 'rtaudio', whose members are granted realtime
privileges.
on a multiuser system, i think it's not necessary to grant realtime
privileges to every user who wants to hear his custom system beeps :-)
cheers, martin
17 Nov
17 Nov
12:16 a.m.
Jack O'Quin writes:
> One of the things I like about the `audio'
group approach is that
> it is easy to administer and simple to verify who has access to
> those privileges.
martin rumori <ptiger(a)gmx.de> writes:
i think, that's a clean solution. to be able to
distinguish between
realtime- and non-realtime-audio users, i'd propose to use a separate
group (e.g. 'rtaudio'), so
(5) introduce a group 'rtaudio', whose members are granted realtime
privileges.
on a multiuser system, i think it's not necessary to grant realtime
privileges to every user who wants to hear his custom system beeps :-)
That's right. Separating the `realtime' from the `audio' seems
logical to me. Not all audio is realtime, and not all realtime is
necessarily audio. Video or other applications could also benefit
from this mechanism. Maybe we should just invent a group named
`realtime'.
Note that the group name issue is separate from the underlying kernel
mechanism. In Debian, group `audio' has gid 29. One should not hard-
code that in the kernel. I would envision a user-level admin process
that accesses the appropriate group name and writes its numeric gid
value with sysctl. The kernel security module would use whatever gid
value it is given.
--
joq
3:40 a.m.
On 2003.11.17 05:15 Jack O'Quin wrote:
That's right. Separating the `realtime' from
the `audio' seems
logical to me. Not all audio is realtime, and not all realtime is
necessarily audio. Video or other applications could also benefit
from this mechanism. Maybe we should just invent a group named
`realtime'.
Note that the group name issue is separate from the underlying kernel
mechanism. In Debian, group `audio' has gid 29. One should not hard-
code that in the kernel. I would envision a user-level admin process
that accesses the appropriate group name and writes its numeric gid
value with sysctl. The kernel security module would use whatever gid
value it is given.
The mechanism you're looking for may be a PAM module. It has all the
information (uid, gids, tty), is trusted, runs at login time, is in
userspace and runs as root.
Melanie
8:53 a.m.
On 2003.11.17 05:15 Jack O'Quin wrote:
> from this mechanism. Maybe we should just invent a group named
> `realtime'.
totally agree. that's even better than an extra "rtaudio" group.
Melanie writes:
The mechanism you're looking for may be a PAM
module. It has all the
don't know too much about pam, but sounds to be a good solution.
martin
6:46 p.m.
New subject: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
At 11:52 PM 17/11/2003, Martin Voelkel wrote:
Melanie writes:
Not all distributions use pam, Slackware being one of them.
Luke
--
Luke Yelavich
AudioSlack Founder and head package maintainer
Audio software packaged for the Slackware Linux Distribution
http://www.audioslack.com
luke(a)audioslack.com
The mechanism you're looking for may be a PAM
module. It has all the
don't know too much about pam, but sounds to be a good solution. 
8:52 p.m.
On Mon, 2003-11-17 at 17:33, Luke Yelavich wrote:
At 11:52 PM 17/11/2003, Martin Voelkel wrote:
The current methods will continue to work for non-pam-using distros.
Taybin
Melanie writes:
Not all distributions use pam, Slackware being one of them. The mechanism you're looking for may be a PAM
module. It has all the
don't know too much about pam, but sounds to be a good solution.
7632
days inactive
7636
days old
linux-audio-dev@lists.linuxaudio.org
32 comments
11 participants
participants (11)
-
Fernando Pablo Lopez-Lezcano -
Jack O'Quin -
Kjetil Svalastog Matheussen -
Luke Yelavich -
martin rumori -
Martin Voelkel
-
Melanie -
Paul Davis -
Roger Larsson -
Taybin Rutkin -
Tim Hockin