| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These are unit tests for converting wire claims into sorted claims v1
structures.
These are based from packets derived from the krb5.conditional_ace
tests, and currently don't test more than they do, but they work about
a hundred thousand times quicker.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
|
|
These are just as readable with `less` as they were with `zless`.
This file has been slightly manually edited to add line-breaks. There
is not an easy setting in Python's json module to get good formatting.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Mon Nov 27 02:10:12 UTC 2023 on atb-devel-224
|
|
We had two sets of test vectors (Windows ground-truth for SDDL
compilation) that got mixed up.
The "oversized ACLs" set is ACLs that contain repeated ACEs, like
"D:P(D;;;;;MP)(D;;;;;MP)" -- Windows will assign a size to the ACL
that is greater than the sum of the ACEs, while Samba will not (in
part because we don't actually store a size for the ACL, instead
calculating it on the fly from the size of the ACEs).
The "TX integers" set is for resource attribute ACEs with octet-string
data that contains pure integers (lacking '#' characters) in their
SDDL, like «(RA;;;;;WD;("bar",TX,0x0,0077,00,0077,00))». We used to
think that was weird, and that RA-TX ACEs should contain octet-strings
in the conditional ACE style. But now we have realised it's not weird,
it's normal, and we have fixed our handling of these ACEs.
As a result of this mix-up, some of the tests labelled as "oversized
ACLs" started passing when we fixed the TX integer problem, and that
was confusing. All of the removed tests are already on the TX integer
set -- the removed ones were duplicates.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
|
|
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
|
|
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>
|
|
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>
|
|
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>
|
