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

[Todd Sabin]

Luke Kenneth Casson Leighton <lkcl at samba.org> writes:

> On 10 Feb 2000, Todd Sabin wrote:
> 
> > Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> > 
> > > > Yes, and there are reasons why HKLM\SAM is NOT a directory with up to 100
> > > > 000 files in it - even Macrosoft code isn't THAT inefficient (usually).
> > > > It's a file (registry hive), with access control implemented by the only
> > > > process allowed to access it.
> > > 
> > > bad example to pick.
> > > 
> > > 1) the SAM is loaded into memfrom what i can tell, at start-up time.  i
> > > may be wrong about this.
> > > 
> > 
> > Actually, it's a whole registry hierarchy.  There is in fact one key
> > and a couple of values per user, alias, and group.  However, the
> > permissions on all of these keys are exactly the same: SYSTEM: Full
> > Control, Admins: Write DAC.  NT's RPC servers implement the
> 
> [and user create+read, on the user-object.  use rpcclient's samquerysec
> command]
> 

No, not on the registry keys, themselves.  One of the pieces of data
inside the V value of each object is the serialized security descriptor
that is enforced at the RPC layer.  The reg keys themselves are all the
same.

> > permissions checks explicitly, they don't rely on the permissions of
> > the underlying kernel objects.
> 
> it's looking that way.  i'm just adding lsa_query_secret, lsa_set_secret,
> and each of hklm\securyt\policy\secrets\nnn has a SecDesc member,
> containing a security descriptor.
> 

Exactly.  The SAM is the same way, except they don't break it out into
separate values.  The Service part of the hierarchy does the same kind
of thing as well.  It's common practice in NT.

> > > 2) the registry is implemented at the kernel level, for "speed"
> > > optimisations.  this results in me being able to modify rpcclient and take
> > > out an NT box with a blue-screen if i have an "authenticated user" SMB
> > > connection (guest, user, admin but not anon-connect).
> > 
> > Actually, it's not implemented at kernel level.  The \winreg server is
> > contained inside winlogon.exe.  Unfortunately, if winlogon.exe exits
> > for some reason (like, umm, someone crashing it), the kernel notices
> > it and actually _forces_ a blue screen itself.
> 
> !

:)  Yes, you can observe this empirically by crashing winlogon
interactively.  They've been making it harder for power users to do
it (gee, I wonder why? :)), but something that has always worked is
attaching a debugger to it, and then closing the debugger.  That terminates
the debuggee.

BTW, in NT5, instead of a blue screen, you get a dialog box notifying
you that the machine will shut itself down in 30 seconds or something.
I guess that's improvement in MS terms.


Todd