[LINK] Schneier on Storm Worm

[Kim Holburn]

I don't think we really disagree on much.  I just think that a lot of  
work needs to be done so that computers do all the really hard part  
of the work on security.

Here for instance
<http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=499>
<http://preview.tinyurl.com/yuznur> is an interesting article on a  
method for fighting phishing being developed by yahoo.  It uses the  
computers themselves to do most of the work.

On 2007/Oct/07, at 9:35 AM, Craig Sanders wrote:

> On Sun, Oct 07, 2007 at 08:17:25AM +0200, Kim Holburn wrote:
>> SE linux is very good but very, very hard to use, to set up.  App  
>> monitor
>> is similarly difficult.  I know good sysadmins who have given up  
>> trying
>> they are so difficult to set up.
>
> yes, i know.
>
>> ACLs have been around for a while but who actually uses them?   
>> They are so
>
> people who really need them.
>
> those who don't really need them don't bother.

It makes me wonder why all this really complex stuff that hardly  
anyone can use or is using has been developed and put in operating  
systems.

>> The fact is that giving all applications no matter where they came
>> from (were downloaded from) the same permissions and access as the
>> user is definitely not wise.
>
> OTOH, giving one software supplier a priviledged advantage is also not
> wise. and it's anti-competitive.  MS loves this approach.

Not if it's open source.

>> ACLs still treat all applications run by the user as though they were
>> the user.
>
> and most of the time that is perfectly adequate.

Actually I don't think that is the case at all.  Most of the time  
applications need to do very little that necessitates access to the  
user's data.

> more fine-grained control over which applications can do what is
> obviously better in many ways - it does, however, increase complexity.
> or reduce utility/flexibility. or both.
>
> when you get granularity of configuration down to that fine level then
> somebody, somewhere has to configure it. if you leave it up to the OS
> vendor then you reduce utility & flexibility (AND give the vendor a
> priviledged advantage).

And that is the problem with that model.  The model where you  
partition off the application and allow some *communication* to the  
user process may allow simpler controls.

> if you allow third-party app developers to setup
> their app's priviledges at install time then you undermine the  
> security
> you're trying to set up.

At the time when unix permissions were being developed all  
"applications" were created by the user himself or herself.  These  
days almost all applications are made by someone else.  Someone not  
necessarily friendly.  Why should these have any access apart from  
what it gets through user interaction - ie the user says you can read  
this file, write to this file, something that is right now directed  
by the user but instead now the application actually has full access  
to everything on the computer.

It is a key point though.  Why should you trust a third party  
developer to decide the products privileges.  There must be some way  
to mitigate this - say having a default set of allowable privileges  
or communications.

> and if you leave it up to the user they'll get
> sick of suffering "Cancel or Allow?" syndrome and just turn off all
> protection.

Linux and Mac's don't suffer from the "cancel or allow?" crap.  The  
user shouldn't be asked that stuff.  It should just work, or not.   
Linux and Mac's do rarley ask users odd questions though and they  
shouldn't.

> all of these factors (security, flexibility, open dev platform,  
> ease of
> use, annoyance, convenience) and others are traded off against each in
> ANY security system. there IS no one-size-fits-all solution. nor can
> there ever be one. what works for one person would be infuriating or
> mind-bogglingly complex or whatever for another.

Just because we haven't thought of much better systems doesn't mean  
there aren't any.

> a common compromise method (adopted by selinux and others) is to
> implement mind-bogglingly complex flexibility, but to buffer the user
> from most of that by having sets of pre-defined "profiles" (e.g.
> workstation, web server, file server, etc) which the user can simply
> choose from as the base for their rules. if that isn't a perfect match
> for their needs then the security system's flexibility allows the user
> to tweak and customise that as needed.
>
> not ideal, but probably the best that can be achieved.

Yeah if you start with that model you get a very complex system.   
Start with a different model and you may get a much simpler but even  
more secure system.

> in any case, no matter how good the technology, it can not save the  
> user
> if they are determined to do stupid and dangerous things.  
> unfortunately,
> many are determined to do exactly that.

Crap.  A really good system can make it simple to have good  
security.  I have seen this in action, very, very simple changes to  
an interface can change a home security system from a completely  
unusable system to a simple effective system.  It's all in the  
defaults and the interface.

> if MS patched up all the security problems of windows (and even fixed
> the design so that it wasn't brain-damaged from a security POV) it  
> would
> be a huge help in getting rid of viruses and worms and botnets.
>
> for a while.
>
> then the vermin who write them would concentrate all their effort on
> social engineering attacks to trick the user into allowing their  
> code to
> do it's evil stuff. and they'd be very successful at it (they already
> are now - with even more incentive, they'll only get better) BECAUSE
> most users are ignorant and completely unwilling to learn anything OR
> take *ANY* responsibility for either their own security or for what
> their computer is doing to other people on the net.
>
> unfortunately, no matter how good the technology there is a bare  
> minimum
> that they MUST know and they're not even willing to do that.
>
> they don't know, and they don't want to know.

Look most people use computers to do things that really have nothing  
to do with computers.  They don't really need to know how they work  
anymore than they need to know how a car engine works.  The computer  
should take care of all of that for them.

> trojans, for example, don't rely on security holes. they rely on idiot
> users doing things ("click here", "install this", etc) without  
> thinking
> just because they're told to.

Yeah and an operating system with reasonable defaults makes it very  
hard to install trojans.

> same for phishing - that doesn't need a technological security hole.
> that just needs an average user.
>
>
>
> in other words, it's not possible to completely idiot-proof
> anything....and trying just lowers the bar resulting in even more
> dangerous idiots.

Very few people percentage-wise really know much about computers, nor  
should they have to to use them.

> and before you take my words the wrong way - they're not idiots
> because they don't know stuff. knowing stuff is just knowledge, not
> intelligence. they're idiots because they're not even willing to try.
>
>
> craig
>
> ps: yes, part of the problem *IS* false expectations caused by
> misleading and deceptive advertising about how easy computers are
> to use. no training required. no knowledge or clue or understanding
> required.

and part, or perhaps most of the system is bad software.

> the reality is that complex tools require understanding, and there
> aren't many tools that are more complex than computers.

Computers are too complex for most people but they are complex enough  
to sort a lot of this complexity out themselves.

> this fact is, however, ignored because it is competing against the
> self-serving lies that billion dollar companies spend vast sums of  
> money
> to promote.


--
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