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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This was caught by the next condition, but this is clearer.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
These are like an object type if the callback (i.e. condtional ACE
conditions) succeeds, otherwise they are ignored.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
With the last caller of check_callback_ace_access() gone, so is that
function.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
To help clarify the logic, we make new functions that separate the
deny and allow cases, which helps keep track of what 'yes' and 'no'
mean and which incorporate the logic of token->evaluate_claims
handling, which determines when we want to run a conditional ACE, when
we want to ignore it, and when we want to take offence. In the case
when we decide to run it, we then need to decide whether to apply it
or ignore it based on the result. This last bit differs between allow
and deny aces, hence the two functions.
These functions will replace check_callback_ace_access() over the next
few commits.
In the case where token->evaluate_claims is
CLAIMS_EVALUATION_INVALID_STATE and the DACL contains a conditional
ACE, the maximum allowed is 0, as if it was a "deny everything" ACE.
This is an unexpected case. Most likely the evaluate_claims state
will be NEVER or ALWAYS. In the NEVER case the conditional ACE is
skipped, as would have happened in all cases before 4.20, while in the
ALWAYS case the conditional ACE is run and applied if successful.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Most tests were prepared in advance, but we left these ones to test
the change.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
By making this specific to the only use case, merging with the SYSTEM
token for GPOs, we avoid having to merge the claims, as there are none
for SYSTEM.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This allows us to punt on the question of merging the claims, as there are
none on the system token.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This helps ensure we have a smaller number of places that
a struct security_token starts from.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
This ensures that the full structure is initialised now and in the
future.
Because this is now a talloc based structure, we can now use
add_sid_to_array_unique() rather than a reimplementation in this file.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
For non-testing callers of auth_generate_session_info(), passing
lp_ctx will allow us to correctly set a flag indicating if claims
should be evaluated.
For testing applications, the default will allow safe operation
inspecting the SID list.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Claims evaluation is added to the core se_access_check() library, but
not all callers provide claims in the security_token and we want to
be able to disable this new and complex code if needed.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
The struct security_token can now contain complex claims as well as SIDs
so we can no longer just duplicate it by hand. Instead let PIDL and libndr
do the hard work for us.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Obviously it works fine, but we don't do it anywhere else.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is a helper module to construct conditional ACEs that can't be
created from SDDL.
There is a semi-infinite number of valid conditional ACEs that don't
have SDDL representations, and an even larger number of invalid (or
borderline invalid) ACEs.
This allows us to create those ACEs without having to deal with too
many array of numbers.
The next commit provides an example of its use.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Now that access_check.c includes headers for conditional ACEs, the patch
should take that into account.
Also, we check for a talloc failure.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This parses the blob as a conditional ACE, and if possible tries
decompiling it into SDDL.
There are not many round-trip assertions we can honestly make, but we
keep the trip going as long as possible, in case it reveals anything.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
When a test fails, this prints a little stanza like
static void test_something(void **state)
{
INIT();
USER_SIDS("WD", "AA");
DEVICE_SIDS("BA", "BG");
SD("D:(XA;;0x1f;;;AA;(! Member_of{SID(AA)}))");
DENY_CHECK(0x10);
}
which is exactly right for copying into
libcli/security/tests/test_run_conditional_ace.c
which is much easier to iterate over with compiling and debugging.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Sometimes we need security tokens for tests, and the raw constructor
is not very ergonomic. This wraps it so you can do this:
from samba.tests.token_factory import token as Token
t = Token(['WD', 'AA'],
privileges=['SEC_PRIV_DEBUG'],
rights=0x840,
device_claims={'wheels': 2, 'smelly': 'no'},
device_sids=['BG'])
and get a security.token object with the expected qualities.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It isn't used and ended up filled with junk. The alignment works out.
Signed-off-by: Douglas Bagnall <douglas.bagnall@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>
Before we had to do this in an environment variable. In that case we
are probably wanting to monitor changes, so we like it to print more
messages than we want to see in an autobuild run that will hopefully
never do anything interesting.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Currently a test suite needs a strings list in order to import new
strings. This lets us avoid that and have the actual tests defined
only in external lists, making it easier to see we're testing the same
thing on Windows and reducing duplication.
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>
This makes it easy to separate a large number of examples into
successes and knownfails.
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>
