l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Back door design


From: Anton Tagunov
Subject: Back door design
Date: Wed, 10 Jan 2007 04:49:03 +0300
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

Anton>     Jonathan if you could build an utmostly secure OS
Anton>     yet having an inspection "backdoor" what would you do?

Jonathan>  Without any hesitation whatsoever I would leave out the back door.
Jonathan>  The problem with a back door is that it will not be used for 
emergency
Jonathan>  purposes. It will be used primarily by everyday administrators and
Jonathan>  companies for improper purposes.

Anton>     Very good point. Let me think
Anton>     I want a back door that shall not be abused.
Anton>     Can we design one?

Jonathan>  People have been trying to do that since the first multiuser 
computer.
Jonathan>  No sign of hope so far.


I think I've designed it :)) Please judge me.

1. Administration

OS runs in one of two modes - opaque (default) and debug.
Opaque mode == no application has been designated as "Debugger".
Debug mode  == there is at least one application designated as "Debugger".

OS Admin GUI has a section used to
* designate any application as "Debugger"
* designate any application as exempt from debugging (irreversible)
* disable debugging completely (irreversible)
To enter this section Admin has to perform a sufficiently arcane procedure [1].

2. Debugging

Any application designated as a "Debugger" can inspect memory of
any application that has not been marked as exempt from debugging.

Application under debug has no way to know this.
This is done so that apps would be unable to change behavior -

    "test what you fly and fly what you test" [2]

Application has no way to know if it's been excluded from debugging either.

Gentlemen, now it's time to throw your stones :)

cheers,
Anton

[1] There is still danger that a DRM vendor could use clever wording
    to talk a naive user into marking his application as exempt from debugger.

    To avoid this danger I suggest that Admin has to go through some
    very explicit and reasonably arcane procedure to enter Admin GUI
    doing the marking.

    An example procedure on a PC could be
    * Ctrl+Alt+Del 10 times with 2 second breaks
    * enter admin password 3 times
    * wait 1 minute with the screen flashing red scull and bones and dynamite
    * chase running away "Ok" button with mouse pointer

    Perhaps such a lengthy procedure shall alert even the most naive.

    Perhaps also some wording could be put into license prohibiting fooling 
user in such way?
    BTW it is an example of a more general case when software vendor would fool 
user into
    giving too much capabilities to his software.
    So this situation should probably be handled legally in any case.
    Legal action could help against big vendors.

    If some malware produced by small guys is talking user into giving it too 
much
    privilege we could perhaps use centrally updated black lists against it.

[2] "test what you fly and fly what you test" is a quoted from

    
http://research.microsoft.com/~mbj/Mars_Pathfinder/Authoritative_Account.html

[3] Special care may be needed to craft proper license. It could say that
    if parts of the OS code are used to build another OS then the debugging 
mechanism
    should be copied "as is"? And that the initial system can not be put into
    "debugging disabled globally" initially requiring a very explicit action
    from the Admin to do so?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]