19 Nov
2003
19 Nov
'03
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.