[Full-Disclosure] RE: [Full-disclosure]MS should re-write code with security in mind. lame bitching about xpsp2

[Frank Knobbe <frank () knobbe us>]

On Wed, 2004-08-18 at 11:38, joe wrote:
> I think you meant your first line to be
>
> "All OS vendors should bite the bullet and re-write their code with security
> in mind."
>
> Not sure why you singled MS out for that statement. Especially considering
> the rest of the post. 

Probably to bait you, and you've bitten :)

Earlier versions of NT (3.51-4.0) had security in mind (perhaps a
heritage from the VMS days...dunno). The web server (up to and including
IIS 3.0) ran under a user account (configured in the services list). So
did the FTP account. It was even possible to run the Scheduler Service
under a dedicated user account. Being able to run processes under
dedicated user accounts allowed the administrators to keep these
services confined in terms of access to Registry keys and the file
system.

Unfortunately, during the course of moving to 2000, all these features
disappeared. The "greed for speed" lumped all services into the System
context. Pretty sad.

I loved NT 4.0. I thought it was great. I had services locked down so
tight, even file system-wise these boxes were pruned (no explorer, just
cmd as the shell). Oh well, now I'm using a different OS and am much
happier with it.


The biggest boon to security would be to start simplifying Windows. Not
from a end-user perspective (as in how easy it is to use it), but from
an architectural perspective. That's where systems like *BSD shine, a
simpler (and thus more secure and faster) architecture. Another thing
that would improve Windows security greatly (besides a *real* host-based
firewall) would be something like the Execute bit in the *nix file
permissions. Seems like Microsoft is trying this through use of a list
of approved/signed applications. That may or may not work (not counting
downsides of administrative overhead). We should keep a close eye on the
success of that. Perhaps a simple Execute-Bit, that can only be set
after entering a password (to foil attempts by hostile code to set it on
behalf of the user), might have been a better solution. Again, a simple
solution with far-reaching effects.

But since Joe No-pun-intended Shmoe at home doesn't want security, it
will never happen. Oh well...


Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part