artswrapper defanged

[Stefan Westerfeld]

   Hi!

(I'll CC this back to the list, in the hope that this contains a few more
 thoughts about "what to do with artswrapper now?").

On Sat, Jul 20, 2002 at 04:37:06PM -0500, Andreas Pour wrote:
> > Can this be "fixed" within artsd? No. You might possibly fix (3). However,
> > you can't remove (2) without removing significant functionality (namely, the
> > ability to have a modular sound server, rather than a monolithic).
> 
> This can be tempered by permitting only root-installed modules to run
> real-time.  If the user chooses a module in his own directory,
> drop real-time.  Sysadmin can override this in some root-controlled setting,
> for single-user systems (though on those I would think modules are installed
> by root anyway).

Yes, you are right. I am reluctant to do this, as loading only root modules
might not be too easy to enforce, as the module loading goes through libtools
.la files. So getting a waterproof solution on all platforms might be quite
hard, as the details on where libraries are searched (such as LD_LIBRARY_PATH
on linux) which are referenced in the .la files might be platform specific.

Also, you probably would need to put a .la file parser into aRts, which means
depending on libtool internals.

> > And even
> > if you do this, still (1) remains. So, with the current artsd and the current
> > design, you have lost in the moment where you have an abusive user.
> >
> > Can this be "detected and avoided" by an external monitoring process or by
> > a kernel extension?
> >
> > Certainly, this could be done by a kernel extension (or a new scheduling policy)
> > which I would consider the most reasonable solution, given that artsd might
> > not be the only RT application, and given that the scenario "you want that
> > RT applications perform nicely, but never tear down your system" is not that
> > uncommon.
> 
> We must deal with the reality that it is not there.  I assume the assumption
> for the current system is that nobody would be (no offense) reckless enough
> to permit just any code to operate at that level.

Why? The CPU-monitoring artsd itself does is sufficient for the case where
your user is not your enemy. On my home machine, my user (that is: me)
is not my enemy. Thus it is safe to run artswrapper there, as bugs are
catched by the self monitoring just fine.

> > I think such attacks are also detectable by an external watchdog process,
> > which has the following properties:
> >
> > (a) it runs at higher priority than artswrapper
> > (b) it _never_ terminates
> > (c) it can't be terminated by anybody (but root)
> > (d) it controls whether an application can aquire realtime rights or not
> 
> I don't see why this part is necessary.

If you don't have (d), then the DoS attack can do as follows:

while true
do
  start artswrapper
  do DoS exploit
  wait until artsd has been depriorized
  kill it again
done

which is a close-to-99.99% effective DoS attack.

> > (e) it spawns a low priority process and watches whether this process gets
> >     CPU time or not
> 
> One way to do it.
> 
> > (f) it depriorizes all other realtime processes IFF the low priority process
> >     is dead for a while, and disallows acquiring realtime rights for a certain
> >       amount of time (60 seconds or so)
> >
> > These properties might make it possible to defend a system even against
> > malicious users trying to abuse realtime priorized applications. Note that
> > the user could still cause significant pauses, but the system would remain
> 
> At least one pause; then you can ask the user before re-prioritizing them.

You can not ask the user, as the user is the one who is your enemy, in the
scenario of local DoS. He could find an automatic way of saying "yes"
automatically and do the 99.99% DoS thing.

> > "life" in the long run. But, it seems that such a watchdog would be
> >
> >  - somewhat non-portable
> 
> Which part, for a system that supports real-time now?

The "process listing / acquiring cpu usage" part, for which no portable
solution exists.

> >  - quite ugly (because you can't kill it as user - if you could, you could
> >    kill it and then do your DoS attack)
> 
> What is ugly about that?  No more ugly than "ulimit", which you also cannot
> change as a user.

Subjective feeling on my part. I would be scared if I logged into KDE and saw
this "artsguard" process running, which I could not kill anymore.

> >  - something that exceeds the scope of aRts
> 
> Probably, but not a strong argument against.

No, you're right about this one. I would even add a configure check or
something like this, if somebody wrote a safe "give RT priority and watch that
nothing goes wrong" solution, so that aRts could use it if it was installed,
instead of going its own, non-safe way.

> >  - something that might affect other processes that were not started by
> >    artswrapper
> 
> Well that is not such a big problem.  For one, you can take the view that
> root-owned processes should not be included.  Other than that, this would
> be a great service anyway, since if the system is frozen and unusable,
> I don't see the problem with blocking non-arts-spawned processes from being
> reigned in as well.  You can of course also make the triggers configurable -
> how many seconds, etc.

Well, it is a big problem if KDE ships it enabled by default, because then
again, people will complain about it. This time not against artsd possibly
tearing their system down, but about artsguard possibly destroying their
pet realtime processes. I know that the number of people affected by this
is smaller than the number of people affected by the problem now, but it kind-
of indicates that the solution is wrong.

What I would _really_ like would be if a process could get a kind of
irrevocable mark by root, which a user could not sweep away, kept during fork()
and clone(). That way, a monitoring process could be perfectly sure that it
really only affects processes which have been marked by it before (when they
asked for RT priority).

> > IMHO the most reasonable way to go is to not change anything. Users can
> > disable realtime if they feel like it in kcontrol. Root can disable realtime
> > if it feels like it by removing the suid bit. Packages can disable realtime
> > if they feel like it by packaging without suid bit. (And SuSE for instance
> > does this, depending on the security level [easy..paranoid). Endusers benefit
> > from realtime. It has worked for ages like it was. Why change it?
> 
> Security advisory.  More importantly, this huge hole has never been drawn to
> the attention of others, which is an issue in its own right.  Who but you
> knew about it?  I, for one, didn't.

The security advisory is out since Monday. I hope that this will be read.

> > Writing the external unkillable watchdog will add an extremely ugly piece of
> > code. I don't think users will be happy to see "artsguard" running even after
> > they logged out of KDE (but it has to, for if you could terminate it,...).
> 
> It could kill itself when no real-time processes are running any more.  For
> most people, that would be when they exit KDE.

Well, the problem is atomicity here. I am not sure if it is possible to get
an atomic snapshot of the process table. If it would be possible, you could
kill yourself when the atomic snapshot doesn't contain any RT processes any
longer. However, if atomicity can not be granted, the exploit of the guard
system will be to fork() and kill the exit process multiple times and hope
that the system will fail to see the old process (which is already gone) but
not see the new process yet.

I just considered the solution that this might be used to fool a watchdog,
but I am not sure if thats a realistic scenario, given that I don't know
what strategies can be used under different platforms to get a list of all
processes, and whether these strategies guarantee atomicity under various
conditions.

> > So I think you should revert your commits, and instead propose changes to
> > the documentation/FAQ/Makefile, if the risks are underrepresented there.
> 
> Well changes there should be made in any event.
> 
> I think the "guard" is great even for people who want real-time.  I wouldn't
> mind running arts realtime now, e.g., but am unwilling to do it given the
> current situation.  Perhaps I am alone in this, though.

Well, as I said, its _safe_ if you have no untrusted users. Its _not safe_ if
you do have untrusted users ; whereas _not safe_ can be spelled out into: if
you have plugged all other holes (i.e. set apropriate ulimits) which otherwise
would allow local DoS attacks anyway - and even the sysadmin at our local
university network told me, that he himself didn't think that his network was
invulnerable to malicious abuse of allocating resources DoS attacks - then
aRts will provide another possibility for DoS which you can't circumvent other
than removing the suid bit from artswrapper.

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