IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These will soon be used by python/samba/tests/sddl_conditional_ace.py,
and are a format understood by the Windows programs in
libcli/security/tests/windows.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
These tests were named in the superclass, but were not actually run,
nor was the file in git.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We have two sets of tests: one that will succeed, and one that is going
to remain a knownfail. The latter involves Resource Attribute ACEs that
have the TX type, meaning "byte string".
In MS-DTYP, a bytestring is defined like "#6869210a", with a hash,
followed by an even number of hex digits. In other places on the web, it
is mentioned that zeroes in the string can be replaced by hashes, like so
"#686921#a". We discover via indirect fuzzing that a TX RA ACE can also
take bare integers, like "6869210a" or "2023". As it would be tricky to
support this, and there is no evidence of this occurring in the wild, we
will probably leave this as a knownfail.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
ACL revision 4 (SECURITY_ACL_REVISION_ADS) is effectively a superset
of revision 2 (SECURITY_ACL_REVISION_NT4), so any revision 2
ACL can be called revision 4 without any problem. But not vice versa:
a revision 4 ACL can contain ACE types that a revision 2 ACL can't. The
extra ACE types relate to objects.
Samba currently simplifies things by calling all its ACLs revision 4,
even if (as is commonly the case) the ACLs contain only revision 2 ACEs.
On the other hand, Windows will use revision 2 whenever it can. In other
tests we skip past this by forcing Windows ACLs to v4 before comparison.
This test is to remind us of the incompatibility.
It would not be hard to fix.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If there are multiple identical ACEs in an SDDL ACL, Windows will decode
them all and put extra trailing zeroes at the end of the ACL.
In contrast, Samba will decode the ACEs and not put extra zeroes at the
end.
The problem comes when Samba tries to read a binary ACL from Windows that
has the extra zeroes, because Samba's ACL size calculation is based on
the size of its constituent ACEs, not the ACL size field.
There is no good reason for an ACL to have repeated ACEs, but they could
be added accidentally.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
As with other object ACEs, if there is not a GUID to refer to the ACE
becomes the corresponding non-object ACE.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
*_CALLBACK_OBJECT types inherit like other _OBJECT types.
*_CALLBACK types do nothing, like other non-OBJECT types.
We also explicitly throw unused alarm callback types and
SEC_ACE_TYPE_SYSTEM_MANDATORY_LABEL and
SEC_ACE_TYPE_SYSTEM_SCOPED_POLICY_ID into the fire.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
With this, Conditional ACEs and Resource Attribute ACEs in SDDL will
be parsed.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Will work when the ace_flags table is updated.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Will work when the ace_flags table is updated.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The decoding will not happen until "RA" is added to the ace_types table.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Conditional ACEs will not actually be decoded until the CALLBACK types
are added to the ace_types flag table.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This doesn't actually *do* anything yet, for two reasons:
1. conditional ACEs are not checked in the
libcli/security/access_check.c functions (or anywhere else), and
will be treated just as they are now, as unknown types.
2. this file isn't mentioned in the wscript, so aren't compiled.
We'll get to point 2 first.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Resource Attribute ACEs have similar syntactical components to
conditional ACEs -- enough so that it is worth reusing the same
functions, but not quite enough so that it is exactly simple.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
There are three different forms for claims, and we need to convert
between them.
For now, we are only going to be converting between conditional ACE
type and the CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1 type used by
resource ACEs and in the security token, and later we will add the PAC
claim types.
It doesn't help that these all have incompatible definitions, but we
do our best.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is to show where we're going to end up.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is just the outline of what will come, but first we'll add
conditional ACE SDDL decoding in sddl_conditional_ace.c
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
tabs not spaces.
It appears that my emacs got its configuration mixed up and was using
spaces.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Only Resource Attribute ACEs and Conditional ACEs are expected to have
trailing data. Others sometimes might, but we don't care what it is.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Because we're going to add more ACE types.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Mirroring the last commit for sddl_decode_sid, we want to be able to
encode SIDs from sibling source files.
The dom_sid functions are insufficient for this because they don't know
the SDDL short aliases, like "WD".
sddl_transition_encode_sid() is used internally.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We are going to need it in for parsing SDDL for conditional ACEs and
resource ACEs, which will go in a separate file because it's huge.
This means changing the interface for `sddl_decode_sid` to that from
before 7d466a913f which introduced
sddl_transition_state to deal ease the shift to disambiguated machine/
domain/forest SIDs. Internal callers use `sddl_transition_decode_sid()`
which is the old function; external callers use the same shim pattern as
the other externally available functions.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Can Samba understand Windows security descriptors? Does it parse SDDL
the same way?
Here we test on over 7000 SDDL/descriptor pairs and find the answer
is pleasing. In later commits we will add more tests using different
classes of ACE.
The test cases are derived from fuzz seeds, exported to Windows via
the script in the last commit, with the Windows descriptor bytes found
using libcli/security/tests/windows/windows-sddl-test.py.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This allows us to try the fuzz seeds as SDDL on Windows, then test
that Samba matches Windows' security descriptors in the cases where
the SDDL compiles. This will find SDDL edge cases that might otherwise
be missed.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This script never worked well because it had to shell out to
Powershell, which never worked well due to syntax conflicts and
Powershell's specialness. The attempted ctypes version did not work,
due to the difficulty in expressing things like "relative
PSECURITY_DESCRIPTOR" in ctypes.
It turns out that pywin32 is easy to install and use, and we can
extract the NDR bytes which is far more useful than just testing if
the SDDL parses.
On Windows:
1. install Python from python.org
2. run `pip install pywin32`
3. copy e.g. libcli/security/tests/data/conditional-aces.txt to Windows
4. run `python windows-sddl-tests.py conditional-aces.txt`
5. add `--help` to see how to export descriptor bytes.
The default output is a whole lot of multi-coloured text, indicating
what failed and what didn't.
With --export-json it writes a JSON file mapping SDDL strings to NDR
byte sequences, which can be used to compare with Samba's attempts. If
you are only interested in --export-json, you might also like --quiet.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We fuzz security descriptors in a couple of different ways, and this
maps seeds from one form into the other. The SDDL examples can also be
used in Windows tests.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Soon we will get Conditional ACEs and Resource Attribute ACES, each of
which have trailing bytes at the end of the ACE. Here's a diagram:
____ The ACE size field may indicate a size bigger
.type / | than the known parts, even when you take
.flags / | rounding to a multiple of four into account.
.size --' | This extra data is meaningful in some ACEs.
.access_mask |
.trustee (sid) _| <- known data ends here.
:
"coda" ___: <- the trailing part, Zero size unless the size
field points beyond the end of the known data.
Probably empty for ordinary ACE types.
Until now we have thrown away these extra bytes, because they have no
meaning in the ACE types we recognise. But with conditional and
resource attribute ACEs we need to catch and process these bytes, so
we add an extra field for that.
Thus we can drop the manually written ndr_pull_security_ace() that
discarded the trailing bytes, because we just allow it to be pulled
into an unused blob. In the very common case, the blob will be empty.
Microsoft does not use a common name across different ACE types to
describe this end-data -- "coda" is a Samba term.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Soon we will have Conditional ACEs and Resource Attribute ACEs. It is
expected --indeed mandatory-- that the SDDL representations of these
ACEs will contain parentheses, so we can't use '(' and ')' to decide
where ACEs stop and start.
This means shifting where we make a mutable copy of the SDDL string
from per-ACE to per-ACL, and allowing sddl_decode_ace() to decide when
its ACE is finished.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
