artswrapper's new braces (Re: artswrapper defanged)

[Stefan Westerfeld]

   Hi!

On Wed, Aug 07, 2002 at 10:28:55PM -0500, Kevin Puetz wrote:
> [...]
>
> arts will drop RT permissions entirely if an untrusted module is loaded, 
> *before* executing *any* code from this module.
> 
> after some further discussion, we settled in the following definition of a 
> trusted module: anything represented by a .la file owned by root. 
> 
> [...]
> 
> Aftre I've actually tested this fix to ensure it does what I intended it to, 
> if feedback is positive, I will commit.

I have a few comments on the patch:

1. as long as artsd doesn't drop RT prio before exec()ing artsmessage, a
   trivial exploit is to provide an own version of artsmessage, which goes
   into a for(;;); loop

2. the .la-file definition might possibly be not sufficient, as I don't know
   whether for instance in some situations libraries in LD_LIBRARY_PATH could
   be used before these specified in the .la file - before you commit the
   patch and claim it to be secure, you will need to ensure this is not the
   case

3. another exploit not adressed by your patch is to start 2 artsds
   simultaneously, each consuming 50% CPU power (for instance as synthesis
   network), which is not catched by the self-monitoring

4. your patch might not address the possibility to start an artsd, let it
   consume all cpu usage (which is detected by the self monitoring only after
   some time), kill it, and start another artsd - which will lead to a
   99.9999% effective DOS attack - to adress this, artswrapper could be
   modified somehow not to give RT prio to artsd for a while after one 
   (possible) DOS attack has taken place

5. I think it might be easier to code (and thus: easier to verify that the code
   actually does the correct thing), if you _never_ load any untrusted plugin
   into an artsd that is started with realtime priority, and inform the user
   about that (i.e. "could not load untrusted plugin ... because running with
   RT prio - either disable RT prio manually or make plugin trusted doing
   chown/mod ...).

   This is because it might be hard to implement to repriorize all already
   running threads (because they not necessarily use Arts::Thread - for
   instance they might be spawned by a specific decoder implementation, such
   as Xine).

And yes, given that "the other solution" (which is writing an RT monitor)
seems to have very ugly issues on its own, I think if a solution in the style
of your solution can adress all these items, possibly this is the best "fix"
we can come up with. Its better than nothing, anyway ;).

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