Subject: Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: Sun Sep 01 2002 - 06:03:17 EEST
I noticed that I was not on the list...
But I have now read the archives.
Kernel changes are not workable - at least not short testm!
It will take ages until that change is available on most computers.
(But if it is the only solution then it is...)
Local DOS/security exploits has traditionally been seen as equally
dangerous in Unix land - computers often run on Universities...
This is the major reason for Linux to be secure even remote.
(if you can not trust the security for a user logged how can you
trust the security of the whole system if the web server is run as
a normal user?)
And remember this IS perceived as serious enough for the
developers of KDE to disable the RT possibility for arts!
The only thing the sound servers need to be able to handle
RT audio are:
* one of the RT scheduling methods.
* locked memory. (Not protected at the moment - hard limits?)
This can be archived with a wrapper that drops ALL other priorities
before running the real application.
- If that drop is done in a safe manner, we have come a long way.
At that point the server with its plugins, can do two things a normal
process can not:
* can dry out the CPU
* can lock up memory - force the system into an out of memory situation
* can fool the monitor into doing something stupid
I have tried to handle this issues in my monitor:
* runs on higher priority than the RT audio application
* only keeps info about RT processes - ignores others.
* uses only static memory structures
- no need to allocate unavailable memory...
- harder to fool into allocating huge amounts of memory itself...
* reduces RT priority of all RT processes at once
- harder to hide the attacking process
Things missing:
* should use a random checking interval.
* should also monitor the locked memory (RSS) of RT processes.
* it should not reduce the priority of system RT processes since
that might be the reason for the DOS attack. [contradicion!]
* it should have a log for the system administrator to look in.
/RogerL
-- Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : Sun Sep 01 2002 - 06:32:42 EEST