[LINK] Schneier on Storm Worm

[Kim Holburn]

On 2007/Oct/06, at 1:41 PM, Craig Sanders wrote:

> On Sat, Oct 06, 2007 at 12:29:18PM +0200, Kim Holburn wrote:
>>> [re: unix-style permissions]
>>>
>>> In 1971, this might have been acceptable: it was 20 years before the
>>> advent of the Web, and the threat model for most computer users was
>>> entirely different than the one that applies today.
>
> actually, real ACLs have been around for years on several unix
> filesystems - including several on linux (at least ext2/3 and xfs that
> i know of for sure, others as well. ext2 and ext3 are THE most  
> commonly
> used filesystems on linux - they are the default/de-facto standard)
>
> btw, for those who don't know, a filesystem is the disk "format"  
> used -
> analogous to FAT or FAT32 or NTFS formats on windows.
>
>
> for almost all day to day usage, though, unix permissions are good
> enough, and very simple to use. the more flexible (and more  
> complicated)
> acls tend to be used only where absolutely needed. and even systems
> that use them, tend only to use them for particular files,  
> directories,
> and/or applications....the bulk of the system using plain old unix
> perms.

Actually they're not.  Bitfrost is a complete redesign of computer  
security with, what seem to me to be such obvious principles, as a  
basis.  People, and especially most people who don't know much about  
computers and even sometimes those who are, are simply not in a  
position to make security decisions on the fly.  OLPC laptops are  
designed to be used by people who may not even be literate and may  
not be able to enter a username/password combination and yet still be  
safe.  Programs running do not get the same permissions as the user  
and may not get access to any of the user's data.

>   The Bitfrost approach
> Principles
>
> Open design
>     The laptop's security must not depend upon a secret design  
> implemented in hardware or software.
>
> No lockdown
>     Though in their default settings, the laptop's security systems  
> may impose various prohibitions on the user's actions, there must  
> exist a way for these security systems to be disabled. When that is  
> the case, the machine will grant the user complete control.
>
> No reading required
>     Security cannot depend upon the user's ability to read a  
> message from the computer and act in an informed and sensible  
> manner. While disabling a particular security mechanism may require  
> reading, a machine must be secure out of the factory if given to a  
> user who cannot yet read.
>
> Unobtrusive security
>     Whenever possible, the security on the machines must be behind  
> the scenes, making its presence known only through subtle visual or  
> audio cues, and never getting in the user's way. Whenever in  
> conflict with slight user convenience, strong unobtrusive security  
> is to take precedence, though utmost care must be taken to ensure  
> such allowances do not seriously or conspicuously reduce the  
> usability of the machines. As an example, if a program is found  
> attempting to violate a security setting, the user will not be  
> prompted to permit the action; the action will simply be denied. If  
> the user wishes to grant permission for such an action, she can do  
> so through the graphical security center interface.
>
> Goals
>
> No user passwords
>     With users as young as 5 years old, the security of the laptop  
> cannot depend on the user's ability to remember a password. Users  
> cannot be expected to choose passwords when they first receive  
> computers.
>
> No unencrypted authentication
>     Authentication of laptops or users will not depend upon  
> identifiers that are sent unencrypted over the network. This means  
> no cleartext passwords of any kind will be used in any OLPC  
> protocol and Ethernet MAC addresses will never be used for  
> authentication.
>
> Out-of-the-box security
>     The laptop should be both usable and secure out-of-the-box,  
> without the need to download security updates when at all possible.
>
> Limited institutional PKI
>     The laptop will be supplied with public keys from OLPC and the  
> country or regional authority (e.g. the ministry or department of  
> education), but these keys will not be used to validate the  
> identity of laptop users. The sole purpose of these keys will be to  
> verify the integrity of bundled software and content. Users will be  
> identified through an organically-grown PKI without a certified  
> chain of trust — in other words, our approach to PKI is KCM, or key  
> continuity management.
>
> No permanent data loss
>     Information on the laptop will be replicated to some  
> centralized storage place so that the student can recover it in the  
> event that the laptop is lost, stolen or destroyed.


<http://dev.laptop.org/git?p=security;a=blob;f=bitfrost.txt>
> The crux of the problem lies in the assumption that any program  
> executing on
>  a system on the user's behalf should have the exact same abilities  
> and
> permissions as any other program executing on behalf of the same  
> user. 1971 was
>  seven years before the first ever international packet-switched  
> network came
> into existence. And the first wide-area network using TCP/IP, the  
> communication
> suite used by the modern Internet, wasn't created until 1983,  
> twelve years
> after Thompson and Ritchie designed the file permissions we're  
> discussing.  The
> bottom line is that in 1971, there was almost no conceivable way a  
> program
> could "come to exist" on a computer except if the account owner --  
> the user --
> physically transported it to a machine (for instance, on punched  
> tape), or
> entered it there manually. And so the "all or nothing" security  
> approach, where
> executing programs have full control over their owner's account,  
> made quite a
> lot of sense: any code the user executed, she ipso facto trusted  
> for all
> practical purposes.
>
>
> Fast forward to today, and the situation couldn't be more  
> different: the
> starkest contrast is perhaps the Web, where a user's web browser  
> executes
> untrusted scripting code on just about every web page she visits!  
> Browsers are
> growing increasingly complex sandboxing systems that try to  
> restrict the
> abilities of such web scripts, but even the latest browser versions  
> are still
> fixing bugs in their scripting engine implementations. And don't  
> forget e-mail:
> anyone can send a user an executable program, and for many years  
> the users'
> instinctive reaction was to open the attachment and run the  
> program. Untrusted
> code is everywhere, and the only defense seems to be tedious user  
> training and
> antivirus software -- the latter assuming it's fully updated, and  
> assuming the
> antivirus makers have had time to deconstruct each latest virus and  
> construct a
> defense for it.

....

> We have set out to create a system that is both drastically more  
> secure and
> provides drastically more usable security than any mainstream  
> system currently
> on the market. One result of the dedication to usability is that  
> there is only
> one protection provided by the Bitfrost platform that requires user  
> response,
> and even then, it's a simple 'yes or no' question understandable  
> even by young
> children. The remainder of the security is provided behind the  
> scenes.  But
>  pushing the envelope on both security and usability is a tall  
> order, and as we
> state in the concluding chapter of this document, we have neither  
> tried to
> create, nor do we believe we have created, a "perfectly secure"  
> system. Notions
> of perfect security are foolish, and we distance ourselves up front  
> from any
>  such claims.


--
Kim Holburn
IT Network & Security Consultant
Ph: +39 06 855 4294  M: +39 3494957443
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request

Democracy imposed from without is the severest form of tyranny.
                           -- Lloyd Biggle, Jr. Analog, Apr 1961