>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!
precisely. it *is* a real threat, and if someone wanted to try to attack using this kind of method, its going to be very, very hard to stop them, monitor or otherwise. >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. this is, alas, not true. to use RT scheduling, you need either root uid or CAP_RESOURCE. if you have CAP_RESOURCE or root uid, you can do many, many things (such as write to /dev/kmem) that can lead to a DOS. the central problem is that there is no way to tell the kernel "this thread should get to run whenever it wants, but do nothing else that a normal process cannot do", and likewise, "this vm address space can lock down up to 128MB of memory". we don't have sufficiently granularity to do this, so we have to grant overly broad access. that in turns means that anything granted such access has many, many more ways of attacking the system than burning CPU cycles or locking down too much memory (and, BTW, i'm not sure if this latter issue is a problem or not with the emergence of process killing logic in the kernel these days). to make this situation better means recognizing the utility of granting very specific resources to be used or more or less exclusively by a single task, even when those resources more or less mean "all of the machine". this is not something that POSIX or Linux provides at this time. --p
