[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Roger Larsson]

On Wednesday 19 November 2003 01.40, Jack O'Quin wrote:
> Roger Larsson <roger.larsson at norran.net> writes:
> > 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.

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...

>
> > 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.

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.

>
> > 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.

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