Stefan Westerfeld wrote:

[ ... ]

> 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 don't think you have to assume the user is your enemy.  Given the
complexity of the system, the data may well be your enemy - e.g. say
there is a buffer overflow vulnerability or infinite loop possibility in
Ogg Vorbis, then someone can freeze your system by feeding a carefully
crafted audio file to you.

Of course a malicious user is the easiest way to exploit a hole.

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

You can fight that by having the monitor place a timestamp in a file
when a deprioritization occurred, and refuse to start a new high
priority process for some time lag - say 5 seconds - after that, maybe
incrementing each time a deprioritization occurs within a specified
window.  This just requires a file with two fields, a time stamp and
counter.  The point really just needs to be to stop the resource usage
long enough that someone has a chance to fix the system.
 
> > > (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.

Right, but I am thinking there are ways to exploit this besides a
malicious user, even if we haven't found them yet.  Given the large
numbers of modules / apps that can be launched RT, I would be surprised
if one of them will not have a data-dependent exploit at some point in
the future (take, for example, the recent data-dependent exploit in
Apache - this did not require a malicious local user).
 
> > > "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.

Maybe so.  Still, there are some systems - including the most
commonly-used one - where a solution does exist.
 
> > >  - 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.

Well, you should be able to kill it as root.  You cannot kill httpd as a
user either, or initd, or many other processes.
 
[ ... ]

> Well, it is a big problem if KDE ships it enabled by default, because then
> again, people will complain about it.

Then provide a way to turn it off.

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

Ibid.
 
[ ... ]

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

Right, you are suggesting that 'getpriority(PRIO_USER, getuid())' does
not work atomically?  Even when the process making the call has a higher
priority than the processes you want atomicity against (since the
process table is always in memory you need not worry about a swap during
the call)?  That would be a greater challenge then, granted, but it
would also seem to be a bad implementation.

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

Perhaps a sensible approach is to disable RT by default on systems for
which no solution exists, and count on users of those systems to help
with a solution if they would like RT by default.  Personally I would
think that Linux users are the most likely to not change default values
or understand the issues, so a solution there would be most beneficial.

[ ... ]

Ciao,

Dre