Andrew Baudouin wrote:
> Outlook has never required root ("Administrator") to work. NTFS is
> based from the ground up on permissions. Windows NT 4.0 and above
> tracked processes by PID and allowed the ability to re-"nice", etc.
NT-Win2k etc has a VERY granular permissions system. And not just for files.
It is possible to really lock down a Windows box tightly but....
> I have already said this numerous times, but the reason that Microsoft
> is insecure as it is is because of the previous attitudes within the
> corporation of "provide the most features, the most user-friendliness,
> and do it as fast as possible, we'll fix bugs later."
Exactly. It's not done by default. And most linux vendors don't do it either.
Trying to strike a balance between security and usability on an
out-of-the-box installation is difficult and something all OS vendors struggle
with. Well, OpenBSD doesn't struggle with it ;)
I actually think the MS permissions system is much too granular and it makes it
very difficult for admin's to understand how to properly lock down a box.
Understanding Windows permissions, group policies, and inheritance order is
important and not necessarily simple. In the *nix world, most situations are
easily covered with the user-group-other basic set of permissions. Special
cases can be handled by ACL's which are at least as granular as the Windows
permission system. I'd be willing to bet that most of the Linux users here
haven't even had a need to use ACL's in their environments.(1)
I think most of MS's security problems come from the desktop nature/feature
support focus of the company as Andrew does. And of course they like to try
and hide complexity behind the GUI. I don't necessarily think it's a good idea
to "dumb-down" security and systems administration when some of these concepts
have inherent complexity. It doesn't make me feel good to press a pretty
little button that says "security". I'd rather have a simpler and more
flexible method to tighten security that requires me to have a certain
understanding of how things work. At the very least, I want the option and let
folks who don't want to worry have the pretty feel-good "secure me now"
button.
Remember, just because it is easy doesn't mean it's simple. Simple is almost
always good (at least in terms of security) but easy is not necessarily good.
OpenBSD is simple but not necessarily easy. The file system permissions
implementations in Windows in Unix provide a great example of what I am talking
about. I feel the permissions/inheritance system in Windows is way too complex
and leads to errors and omissions. It's certainly simple to change permissions
but do you as an admin really understand those details? Are my changes going to
propagate into subdirectories? What about when group policy is re-applied from
the AD controller?
The everything is a file and file system permissions model of the *nix world is
simple and demonstrated to be extensible for more complex situations via ACL's,
sudo, and RBAC(solaris-specific thing). And I can make things much easier by
using Bastille and any number of other lock-down scripts.
MS has made some other mistakes in the way their server software (IIS, MSSQL)
etc are implemented and the permissions those processes run as. Again, this is
related to trying to make these easier. And Unix has made similar mistakes
though it's _much_ more common nowadays for applications to drop permissions
after opening ports or run in chroot environments in unix.
I also think MS's tight integration (think Exchange/Outlook/Office) offers lots
of (potential) user benefits but provides unique vectors for virus infection
and exploits that you just don't see in *nix. Firefox vs. IE anyone?
(1) ACL's in the linux world are filesystem/kernel specific. A lot of
distributions include the support but it's not well-publicized. I've mainly
used ACL's on Solaris at work but the LInux implementations are pretty much the
same.
--
Scott Harney <[EMAIL PROTECTED]>
"Asking the wrong questions is the leading cause of wrong answers"
gpg key fingerprint=7125 0BD3 8EC4 08D7 321D CEE9 F024 7DA6 0BC7 94E5
