[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080812083204.53602192@lxorguk.ukuu.org.uk>
Date: Tue, 12 Aug 2008 08:32:04 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: daw-news@...berkeley.edu (David Wagner)
Cc: daw@...berkeley.edu, linux-kernel@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon
access scanning
> theoretical possibility)? There are a few obvious ones: files shared
> over a SMB filesystem; attachments sent via email. What else? Can
> you give some other examples?
This is the nightclub model and doesn't work viz:
"If I put a big scary man on the door nobody will be able to get knives
and drugs in because we only have one door for the public"
If you have to enumerate the potential attack vectors to make your model
work you already lost. There is one of you and a lot of them. Smart
nightclubs don't do that they circulate looking for evidence. Yes, they
will miss some, yes they will respond late to some, but they will at
least notice there has been a problem.
Now computer security is a bit different because it has some night of the
living dead type properties where the zombies don't just sneak in through
the toilet window but they go around turning security guards into zombies
too but the basic premise is very much the same.
> Are we talking about enterprise networks? Are we talking about consumers?
What theat model and set of security properties does this change ?
The reasons for poor security may change from 'who cares if we get a
virus, I get an afternoon drinking coffee' to 'not computer skilled' but
the basic problem is very similar.
What are the invariants and what are the probability based things we are
trying to achieve ? What level of interference with existing behaviour is
acceptable ?
The last is important as we SELinux you can achieve much of what is
needed but only at a cost of interfering in normal practice now and then
- eg downloading a shell script versus accidentally downloading a worm is
rather hard for a PC to tell apart so implementing 'written by web
browser, can't be executed' is easy but has side effects
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists