On Tuesday 11 October 2011 16:33:39 you wrote: > Once the screen locker crashes, security must be assumed > broken (if only by visual access). > Therefore the locker must not crash full ack, we have to be at 0 crashes in KWin (which has to be our goal for Wayland anyway ;-) > and if it does, re-established asap the implementation does exactly that > (and best: log the incident and message the user) that is a good suggestion. I will think about how I can add that. Though if someone breaks by crashing kwin he is also able to remove any log. So this could be just snakeoil. > > This is of course no different for any kind of screen locking process. > > As kwin is nevertheless a pretty complex piece of software, one *might* > end up providing a 10 line X11 only watchdog process which monitors kwin > and if it crashes > a) grabs the server and paints it black > b) ensures kwin to come back (in locking mode) might be an idea > > This is not very eye-candy, but a (pot. only optional) LLoD (for more > hostile environments than joe users living room - while i must admit > that systems that keep or access really crucial information... well, > let's say KDE doesn't fit them at all. > And neither would MacOS or -omg- Windows ;-) Yes it must be clear that no screen locker can protect against the German customs officers at Munich Airport who want to install some malware. If someone has physical access to a system he will be able to break it. > > > I myself have never run into a situation where KWin did not restart > > except for development issues (broken setup due to incompatible > > Oxygen client deco and Oxygen lib or PEBKAC during development). > > Any overflow has the potential to invalidate signal handling, but it's > of course nearly impossible to predict or enforce. > And of course if you manage to crash out the counter. True for all screen locker implementations.
Cheers Martin > > Cheers, > Thomas
signature.asc
Description: This is a digitally signed message part.
