Conflicts between access_check in [MS_DTYP].pdf and se_access_check in Samba

[Richard Sharpe]

Hi folks,

I just checked section 2.5.4.1 of [MS_DTYP].pdf and it seems that
there are some differences that might be important.

This is what access_check is described as doing. It takes a Security
Descriptor, an Auth Context and an Access Mask. (It takes a couple
more parameters but that is not important here.)

Firstly, check to see if SECURITY_ACCESS is required and if so, if the
Auth Context contains SeSecurityPrivilege, remove that bit from Access
Mask.

Then, check if WRITE_DAC is required and if so, if the Auth Context
contains SeTakeOwnershipPrivilege, remove that bit from the Access
Mask.

(Actually, these are slightly confusing in the document, but I think
this is the intent.)

Then, check if Auth Context contains the Owner Sid from the Security
Descriptor, and if so, remove WRITE_DAC and READ_CONTROL from the
Access Mask. (Note, this has to change a bit because of OWNER_RIGHTS)

Then, For Each ACE in DACL DO

    if ACE.Flag does not contain INHERIT ONLY then
        case ACE.Type:
        ALLOWED: If ACE.Trustee is in the Auth Context, remove those
bits in ACE.AccessMask that are also in Access Mask

        DENIED: If ACE.Trustee is in the Auth Context and any bits in
ACE.AccessMask remain in the Access Mask, return STATUS_DENIED. (This
is important. See below.)

        end case

    fi
done

The fact that access checking stops on hitting the first DENIED bit is
why Microsoft says that Denied Entries should appear before Allowed
Entries and is different than the way Samba does things.

In particular, if an ACL is ordered in the canonical manner as prescribed by MS:

    Explicit Deny ACEs
    Explicit Allow ACEs
    Inherited Deny ACEs
    Inherited Allow ACEs

Then there are cases where se_access_check in Samba will deny access
when Windows would no.

For example, if there was an ACL containing:

    Allow: R,W:Explicit
    Deny:W,WDAC:Inherited

Windows would allow an open that only asked for R,W access while Samba
would Deny it I believe (because we add back the denied bits in
se_access_check:

        /* Explicitly denied bits always override */
        bits_remaining |= explicitly_denied_bits;
)

There is discussion on the web that the MS approach allows true
discretionary control in that the owner of a file or folder can
override inherited DENY bits if they desire.

I will try to work up some examples to check if this is correct.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)