[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002a01c22c48$336500c0$0a00a8c0@violetclub>
From: mail at blazde.co.uk (Roland Postle)
Subject: Counseling not to use Windows (was Re: Anonymous surfing my ass\!)
> > The fact that 99% of Windows users are clueless is no reflection on
Windows'
> > actual security.
>
> But Microsoft touts "ease of use" which lulls people into believing that
> you don't need as much skill to use or secure Windows as UNIX. And that's
> irresponsible.
I perhaps should have said it's no reflection on Windows' security relative
to unix. It is of course Microsoft's responsibility to make Windows more
secure for the average clueless user, especially given that their
advertising campaigns are so obviously directed at the clueless user.
> These are granular indeed, and confusing as hell. A good security model
> should be simple; the Windows one is anything but. I can probably outline
> the UNIX security model in 300 words. I challenge any Windows user to do
> the same for Windows.
>
> And complexity is the enemy of security. It can lead to misunderstanding,
> incorrect implementation, and ambiguity.
Agreed complexity is the enemy of security, but unix file permissions are
nothing but an unfortunate relic of the past. Owner and world permissions
are a good start, and very useful. Group permissions are just a glance in
the direction of a proper ACL. If a user wants to give access to another
user to a file can they? Not unless those two users happen to be by
themselves in the same group. The user has to give all other users in the
same group (or worse, everybody, if they happen to be in different groups)
access to the file.
Then we come to the suid/sgid bits. What are they really about? It took me
over a year of using unix to figure it out. If this file is executed it runs
in the security context of it's owner and/or group. Is that a permission? It
certainly isn't a permission that refers to a user. It refers to something
the file can do, and that's very different from whether a user can
read/write/execute it or whatever. The idea is to create 'program domains'
(what a program can do or can't do, as opposed to what a user can do or
can't do), but the fact that they're implemented as user domains is another
fudge. And an extremely confusing one at that, because many unix programmers
don't fully understand the distinction.
Windows is no less confusing, but as Paul pointed out, it is at least
functional.
- Blazde
Powered by blists - more mailing lists