[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: aRts as KDE2.0 audio server
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1999-09-18 11:21:58
[Download RAW message or body]

   Hi!

On Sun, Sep 12, 1999 at 12:45:20PM +0200, Stephan Kulow wrote:
> > Now to the rational reasons, why not using CORBA:
> > 
> > - you may think it is slower (in CPU sense)
> > 
> >   as it is NOT used for signal transmission, there is no reason while a
> >   CORBA based audio server should be slower than a non CORBA based
> > 
> > - you may think its more complicated
> > 
> >   as you can write wrapper libs for CORBA just as for esd internals, I see
> >   no reason why this should be the case
> > 
> > - you may think it uses more memory
> > 
> >   I agree here - there have been no benchmarkings on that yet, but before
> >   you start doing them, I'd like to have aRts running with tinymico (that
> >   is with ministl)
> > 
> I think, it's more unsecure. You've mentioned that aRts is going to be
> run
> as root. Can you asure CORBA is secure enough not to let anyone play on
> my computer who wants to?

I think you have two issues here.

1) aRts is going to run as root, so people who can attack aRts will get
full control of the computer.

I've tried to do a fix for that, it's in the CVS under

  kmusic/ksynth/src/shellutils/artswrapper.c

The idea is to start artswrapper suid root, which then in turn changes the
priority, drops the root rights and starts artsserver.bin. Thus, you have
a 50 lines C program, which should be easy to understand, and doesn't use
any special tricks anyway (no CORBA, no Qt, no X11, no C++, no STL,...).

On the other hand, you have artsserver.bin, which is running with higher
priority, but under the rights of the user.

What remains to discuss is under which conditions a wrapper program can be
absolutely sure that if it's execing for instance

/usr/local/kde/bin/artsserver.bin

it will really exec an unchanged binary. I currently say, that if each
component of the path (e.g. / /usr /usr/local /usr/local/kde) is owned
by root, nobody should have been able to tamper with the binary.

Anyway, the maximum harm which can be done is writing a for(;;); binary,
which in turn takes the computer down, as it has higher priority than the
other tasks. (The root rights are gone already). But of course, that is
bad enough.

2) CORBA is no good way to achieve network transparency, because it isn't
secure.

If that's the case, and can't be fixed, it would be bad for a whole lot of
KDE2 apps, which all use CORBA to be network transparent. The fix would be
to use Unix Domain sockets for aRts (as it is currently done for the other
K2 apps), but of course that would loose network transparency.

If that really is a problem, some less complex tasks (like playing streams
or wavs) could be handled over a seperate TCP interface aRts could offer
beside the CORBA interface, but that would be really ugly.

Anybody has more detailed information about the security of Mico with TCP
ports in the real world?

Can we get that secure?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

[prev in list] [next in list] [prev in thread] [next in thread]