ACL / SDs

[Michael Stockman]

Hello,

> > > surs_sid_to_unixid(&sid, SID_NAME_DOMGRP, &unixgroups[i]);
> > > }
> > >
> > > _then_ do a setgroups(n_unixgroups, unixgroups);
> > >
> > > i think.
> >
> > Why? If the SIDs are in the struct they sure haven't mysteriously
> > materialized there, and then someone have already looked them up
...
> > the looked up unix data is as good as the NT data, no gain to
> > relookup. I still think they should be stored in the user_info
struct.
>
> funnily enough, i was thinking of this, too, just now.
>
> it's a matter of which you want to do.
>
> do you want: the PDC to tell you what groups the user is in?
>
> do you want: the local unix system to tell you what groups the user
is in?

On the samba server, yes you do.

We've defined that samba is within the UNIX architecture.

A user on a samba system is a unix user, mapped to an actually virtual
NT user (same with groups). It should be possible to map between the
two (saying that unix user john corresponds to NT's user JohnDoe in
domain xyz). The issue is the same as the SURS discussion has rehashed
sooo many times, a virtual NT user may not be in the local samba
server's domain (which would make him a mapped external NT user) but
does most certainly correspond to a local unix user.

On the computer a unix user have got a set of group memberships,
regardless of whether if he also has an account on another system and
that account have group memberships. We cannot override this and grab
local group memberships from a remote system, which may not even know
about unix and samba. However, if someone would ask us about the group
memberships of a mapped external NT user (could this happen?), we
should tell them what the remote domain told us.

> if the PDC is in fact a samba server, and it created the groups from
the
> local unix system, and the two local unix systems use the same
remote
> unix-group-database, then what's the difference?
>
> well, actually, there _is_ a difference, because both systmes *may*
use a
> different SURS table, that is configured for each local unix system.
what
> hapopens is this:
>
> user logs on.  PDC grabs unix groups (gid_t*).  convverts each gid_t
to a
> group RID with its *local* SURS table.
>
> group RIDs are transferred from PDC in NET_USER_INFO_3 structure to
local
> system.  group_rids converted to gid_t with *its* local SURS table
into
> gid_t* groups relevant ONLY to that local unix system (hi jeremy,
you
> taught me this one :)

This should not happen. If the RID is obtained from the network it
must be looked up on the local system (not may be looked up). gid_s
from a remote system are completely meaningless to us.

> for those people who may be thinking, "eh???", here's the crunch: a)
the
> two local SURS tables *may* contain identical lookups b) this
results in
> both local unix systems following the posix convention of usnign the
same
> local uids and gids to give the impression that both systems have
remote
> groups, and the user on both systems sees a consistent user/group
> view-thing.
>
> you get the idea.
>
> anyway, this is pretty off-topic for what you wanted to discuss,
tim, i
> should imagine.

So, in cases where samba is a PDC we'll only need to do the lookup
once (when we create the NET_USER_INFO3 struct, on login) and when we
are domain members (etc.) we'll need to do a lookup once (when we get
sent a NET_USER_INFO3 struct, on login). Ok, this was easy :-).

> > Well, even NT has banned them from ACLs. Don't let the fact that
the
> > code is the same in NT hide the fact that the bitmask in ACLs is a
> > different bitmask from that by which you request a set of
permissions.
>
> .. oh god.  well, that only makes the implementation of
SeAccessCheck
> complicated, nothing else.

Not much, most bits are shared, except that some are only allowed in
one and not in the other. I'm thinking of possibly hijacking some
unused bits in the ACL.

> ACLs and security descriptors are... pretty dumb.  you can put
anything
> you like in them, and this _can_ do a lot of damage, and it's
totally your
> own fault if you do this.
>
> > > > Example of ACL, tell me what MAXIMUM ALLOWED should return
(and
> > why):
> > > > ACE allows 0x7FFF
> > > > ACE denies 0x0001
> > > > ACE allows 0x8000
> > > > These three ACEs apply to the user.
>
> hey, that's so cool!  it _is_ an effective acl, it's just not
obvious
> what's going in, and trying to create a MAXIMUM_ALLOWED is
impossible :-)
> :-)

--- from readme.sd (my creation) ---
access_mask acl_get_max_allowed( ACL *pacl, access_info *pai )
  pacl = pointer to ACL structure
  pai = pointer to access_info structure

Traverses an ACL collecting allow and deny bits for the user. It stops
when it
finds an ACE with deny bits after the first allowing ACE (but that ACE
is not
evaluated), or at the end of the ACL. The return is then all allow
bits
collected up until the breakpoint with denied bits masked out.
See acl_check_access for info about the access_info structure.

Example ACL, all ACEs are assumed to be applicable to the user
ACE denies 0x000F
ACE denies 0x0010
ACE allows 0x007F
ACE allows 0x0080 <- The acl is evaluated to here
ACE denies 0x0100
ACE allows 0xFE00
The return value will be 0x00E0, all allowed bits (0x00FF) with the
denied
bits (0x001F) masked out. The denied 0x0100 is never evaluated in this
case
and would not affect an access check for the returned bits.

Return value:
  access_mask with the user's allowed access to an object
--- end of cut ---

The return value will be 0x7FFF. This is a simple scheme, but I think
it will do. It avoids many complicated questions like, is it better to
have bit 5 instead of bit 4? Are bits 7 and 8 better than bit 2? One
could also imagine not breaking until an ACE that denies a bit
currently allowed, but it'll get harder to determine in advance what
result can be expected for a given nontrivial ACL. Or why not wait
until you find an ACE that denies more bits than it allows (ok, I'll
do without bit 4 if I can have 8 and 10 instead)? No, I think simple
is good.

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se

PS Sorry about the lengthy NT/UNIX user stuff in the beginning, I
couldn't resist.