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

[James Sutherland]

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

> On Wed, 9 Feb 2000, James Sutherland wrote:
> 
> > On Thu, 10 Feb 2000, Luke Kenneth Casson Leighton wrote:
> > 
> > > > Worse than useless, IMO - you do NOT want users to have access to the
> > > > FILE, only (some of) the contents - and only when accessed via RPC, NOT
> > > > when access as files...
> > > 
> > > so you want /etc/passwd to be made root-only access, right, on all UNIX
> > > systems across the world, right?
> > > 
> > 
> > No. Do you want /etc/shadow world-WRITABLE, so users can change their
> > passwords? Or create a couple of files PER USER? Neither seems like a very
> > good idea.
> 
> i will be either creating a SYSKEY-like algorithm (and to hell with anyone
> who thinks it's an implementation of microsoft's reasons why syskey is
> used, that's NOT why i need it)

Doesn't sound like a good idea, if you're planning what I think you're
planning... Crypto is NOT a proper solution here. Remember the users will
have big chunks of known plaintext, and access to the source code - in
which case, it would need to be a VERY tough algorithm (therefore subject
to export restrictions etc.) - and you just end up with a privileged
private key file, which only your daemon may access, in order to control
access to the data files.

> or creating an equivalent of /etc/shadow

A good plan - there are reasons why this is the "normal" way of doing
things :-)

> or just giving up because i'm fed up with having to explain things in such
> detail when  it hurt like hell to just damn well type.

Hey! I'm the one typing one-handed here with his right arm in a cast...

> or just not explaining it, just getting on with it.

Oh dear... At this rate, MS will want to adopt your code. It'll have even
more security holes and "undocumented features" than their own.

> > More to the point, the SAM permissions do not correspond to file
> > permissions.
> 
> yeah?  and??  so my job is made easier by mapping to the best
> unix-file-sec i can and special-casing everything else.

The best mapping being rw-------, with EVERYTHING as a "special case".
Just like every other time this problem has been solved in the Unix
world...

> and?? what's the problem?

Producing code with a rotten implementation, lots of unnecessary syscalls
to achieve nothing, a false sense of security...

> > OK, you could split user attributes up into three categories
> > (things they can change, things they can read, and things they cannot
> > access at all), and then have three files per user (YUK) - or just do it
> 
> actually, i will need two per user (passwords and everything-else).

Oh dear.

> and you need... so far, i count about 16 separate single-key databases to
> hold a full SAM database implementation.
> 
> that's if you don't go for a file-per-user, file-per-group,
> file-per-alias, file-per-user-members, file-per-group-members,
> file-per-alias-members system
> 
> which i'm considereing

Oh dear oh dear.

> in which case, you have to hold these in directories else it's a mess.
> 
> see HKLM\SAM\... for details.

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.

> > the normal Unix way, and have the file accessable directly only by the
> > daemon, which then performs its own access control.
> 
> right now, i don't want to have to do that.

Are you paid per KLOC or something?! You don't want to resort to the
accepted, efficient, secure way of doing it because - what?


James.