SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[James Sutherland]

On Thu, 10 Feb 2000, Luke Kenneth Casson Leighton wrote:

> > > This trick is bad. The SAM daemon should only open its DB at startup and
> > > after any event where it must close it for maintenance (say,
> > > rewriting). Access to the records in SAM db must be controlled not by
> > > the DB's file permissions but by code in the SAM daemon (and ACLs,
> > > implicit or explicit, in the SAM DB).
> > 
> > Agreed - if Unix file permissions are used, then either users have full
> > access to the entire SAM file, or no access to it at all. Neither is
> > really desirable, I suspect? :)
> 
> well, that's microsoft's stupid fault, they shouldn't have allowed
> anonymous access to the damn SAM database over DCE/RPC.
> 
> i.e if you can get the SAM remotely using DCE/RPC, who give a *monkey's*
> if the same info (and only the same info) is available by telnet to a box
> and vi some-sam-database-file????

One problem: If I can write the password list file (so I can change my
password), I can also write to anyone ELSE's password entry. Not to
mention read their (plaintext equivalent) password.

I know there are problems (BIG problems) with NT's protection (or lack
thereof) of the SAM database, but I didn't think it allowed anonymous
users to download the passwords?

The key question is: Is my Unix user allowed to access (read AND WRITE) my
account info directly? Is it allowed to access OTHER users' entries? The
only way to keep my account separate from others using Unix file
permissions directly would be to have one (or more) separate files PER
USER. Even then, I would be able to make various changes to my account
which shouldn't be possible, I suspect.

As I said, the best approach does seem to be keeping a single Unix-style
database, accessed only via a daemon. Do I need write access to
/etc/shadow to change my password? Of course not (even if NIS+ is that
generous...!)

James.