On Mon, 9 Jul 2007 05:18:49 +1000, "Ian Semmel"
>We all know that viruses and hackers etc have caused a great deal of damage
>to computer systems and the response has been to increase 'security'.
Yup. Tho I'd look more at "safety" than "security" as I see these
operating at different levels of abstraction, with "sanity" being the
level that "safety" rests upon.
It's no good ensuring only User X is allowed access it what happens
when User X is working is not what User X intended.
It's no good designing safety for User X, so that only what User X
wants to happen, happens, if the working code can be exploited to do
completely different things, i.e. is no sane.
In the above, "no good" doesn't mean "useless to try" so much as
"cannot be relied upon to produce the desired outcome".
>However, when these security improvements result in systems being unusable,
>people tend to turn them off and have no security.
Hands up all of you who are sick to death of reading "if the user was
not logged on as administrator..." as a "mitigation"?
IMO, that user identity model has no place in consumerland.
>It is different for a commercial enterprise which can employ a network
>nerd to twiddle with settings and policies etc, but for the average user
>it is often too much.
Note that these enterprises are unlikely to hire a system
administrator without an MSCE. What's the point of a security design
for consumers that requires an MCSE to manage?
>Look at what happens in Vista. You may have a local network that works in
>XP, you upgrade to Vista and then the network doesn't work any more because
>they have 'improved' the security when it probably didn't need improving.
There's one item I can think of that has to die, and that's a form of
password hashing that old Windows tends to rely on.
>Most people use some sort of router which has a firewall built in, there is
>Windows Firewall and often another firewall such as PC-cillin or Zone Alarm
>getting into the act. It all gets to be too much. To get things to work,
>people will turn the firewall off. Same with UAC.
Yep. We used to have a better way, but MS broke it in XP.
>What we need is a single button which says "I want to be able to have a
>local network on which I can do anything I want, I don't want anyone from
>outside my network to access my computers". Clicking this will result in the
>OS working it all out for you.
Vista does try to do that by design (and IMO a very elegent design it
is, too). Instead of multiple tabs full of checkboxes and radio
buttons, it asks "is this network public, private or (whatever the
third option was, prolly domain-based)?"
Which is sort-of OK, as long as:
- you don't open up your LAN via WiFi
- you have a clear edge between Internet and LAN
We used to have a very easy solution to both of the above:
- use cables, DUH
- don't use TCP/IP on your LAN
But nooo, we had to drop NetBEUI for TCP/IP because the latter was
"better". Less packet traffic clogging up 1000-seat networks!
Ability to route traffic all over the world! Seamless integration
with the Internet! 2 out of 3 things WE DON'T WANT.
So now you're obliged to wave File and Print Sharing (F&PS) over
TCP/IP, and hope your "edge" separates this from Internet access. The
same LAN card carries both Internet and LAN TCP/IP to... what?
A router in NAT mode, you hope, but it could be a router dumbed down
by the ISP's "EZ-Setup" bundleware to act as a dumb bridge, or maybe
you have a "modem" rather than a "router" and one of your
richly-exploitable Windows boxes has to pretend to be the router via
Internet Connection Sharing (ICS).
So now all your firewalls have to fuss with your F&PS traffic, which
it often breaks, whereas before it was on a different network protocol
that was physically incapable of being routed beyond the LAN.
Then let's look at what you share over F&PS over what you hope is only
your LAN, rather than the Internet or anyone in extended WiFi range.
Common sense says:
- share as little as possible
- do not write-share code locations or startup integration points
Instead, we have hidden admin shares waving all of every HD volume for
full access. They are only "hidden" from you any programmer can use
them, the names are always the same, no "inside info" required.
But that's OK, says the party line these shares are not exposed in
Vista (hooray!) and are only exposed in XP Pro if the user account is
not null. But XP's Tasks require a non-null password to work, so many
XP Pro systems have weak account passwords as a paper barrier to
anything that can take a poke at F&PS.
We need a different "security" model in consumerland... let's call it
"trustworthy computing". Imagine if you could trust:
- data not to act as code
- the UI to show you what was data and what was code
- the OS to enforce what the UI showed you
- apps to do only what you chose them to do
Are we close to this? No, if anything, Windows design is moving in
the opposite direction. We still break the first three trust points:
- overy-dumbed-down "Open", not "Run" vs. "Edit" vs. "View"
- code files can define their own icons
- file name extensions are hidden by default
- Vista "opens" on hidden content cues, not extension
- no type discipline, i.e. GIF in a .JPG "opened" as GIF
It used to be as easy as "don't run .EXE, .COM or .BAT files", in the
"difficult" DOS days.
In the new "easy" Windows days, how easy is it to be sure the file you
"open" is just "viewing data" and not running code?
Now let's look at the last item in detail, because this is a new
concept, rather than something we had that got broken.
Imagine if every app had to disclose, in broad easy to understand
terms, what it did? For example...
"Dancing Pigs" is a Screensaver, which:
[_] Accesses user data stores: (Details)
[_] Accesses Internet: (Details)
[_] Automates the system: (Details)
[X] May be automated by the system: Details
[X] Is integrated into the system: Details
[_] Is associated with these file types: None
....and now let's imagine the OS actually enforced these things.
This creates "security boundaries" that are meaningful in
consumerland games can't touch data, accounting apps can't interact
with Internet, downloaded toys don't "call home", apps don't
unexpectedly integrate themselves into the OS, etc.
That's much better than "pretend to be several different people with
different job descriptions when you use your own PC" BS that we get
shoved at us via a "one size fits all" design geared to big networks.
It's not easy to do, though, because there's a large surface area
between these contexts, and context drift exploits are likely. It's
hard enough to impose security zone or user account permissions, let
alone per-app scoping. What happens when different vendors call
common shared code libraries how is the context tracked?
Imagine one thing: That the 95% of spam that is currently spread via
botnets, couldn't be sent from infected PCs because only the
designated (and non-automated) email app was enabled to sent out mail
>-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
>-------------------- ----- ---- --- -- - - - -
