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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If ‘int’ is a 32‐bit type, then 1 << 31 cannot be represented in an
‘int’, and this shift will invoke undefined behaviour.
We have got away with this so far because of a Pidl bug that changed the
expression to ‘(uint32_t)1 << 31’, which is valid. But that bug is about
to be fixed.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The same flag will be used in conditional ACE composites, and on
CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1 structures derived from wire
claims and resource attribute ACEs, when we know we have checked the
claim has no duplicate values.
Resource Attribute ACEs contain CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1
at rest, but we are not going to set the flag there on the off chance
that the ACE could fly off to another application and have another
application specific meaning there. We will only check for uniqueness
and set the flag on ephemeral copies of resource claims during access
check operations.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This region is "available for application-specific data" in the
CLAIM_SECURITY_ATTRIBUTE_ space, according to [MS-DTYP] 2.4.10.1,
so it nicer to use that, even though we are not actually setting the
flag on the V1 claims.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This allows it to align with
CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1.flags, with which it shares
values and will soon share more.
It was 16 bit because we needed few flags, and at one point .type was
8 bit, so 16 bits packed nicely into a smaller struct.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
[MS-LSAD] got new functions in order to use AES encryption
and other security related features.
For our servers we still pretent we don't
know about the new functions and return DCERPC_FAULT_OP_RNG_ERROR.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Allowing this broke a round-trip decode-encode fuzz test. Credit to OSS-Fuzz.
REF: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62742
(Comments are from an earlier commit by Douglas Bagnall <douglas.bagnall@catalyst.net.nz>)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Mon Nov 13 02:30:23 UTC 2023 on atb-devel-224
This requires that, other than termination, no NUL (\0) codepoints
exist in the input string, because bytes beyon that will be lost
in the output string.
This in turn causes trouble for round-trip testing, so it is easiest
to reject it upfront (on an opt-in basis).
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>
(there will be a SERVICE_FAILURE_ACTIONSA variant also)
Guenther
Signed-off-by: Günther Deschner <gd@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The LIBNDR_FLAG_ namespace is getting dangerously full, with only a
single flag value (1 << 9) remaining for use. After that flag is put
into use, we won’t be able to add any new flags without increasing the
flag width to 64‐bit.
Up to now we’ve used a haphazard mix of int, unsigned, and uint32_t to
store these flags. Introduce a new type, ‘libndr_flags’, to be used
consistently to hold LIBNDR flags. If in the future we find we need to
move to 64‐bit flags, this type gives us an opportunity to do that.
Bump the NDR version to 4.0.0 — an major version increment, for we’re
changing the function ABI and adding the new symbol
ndr_print_libndr_flags.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
One advantage of this is that the type of the switch value is no longer
tied to the type of the NDR flags.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Represent the message data, structures and constants to do with the
WSP (Windows Search Protocol) as idl.
(see: https://msdn.microsoft.com/en-us/library/cc251767.aspx)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Let PIDL take care of encoding SMB2_FILE_POSIX_INFORMATION. This way
we also get parsing.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
‘bool_value’ has the same type as ‘uint_value’. Removing the former
avoids our having more duplicate code than is strictly necessary.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
A consequence of this is that we remove the confusing "length"
from the IDL, as it was the internal UTF8 length, not a wire
value. We use null terminated strings internally now.
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>
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>
Conditional ACEs go into a DATA_BLOB just like the default ignored
coda, but we add a union field with a different name to preserve
sanity.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
And now we see why security_ace_coda was a union.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
At some point sec_ace_object() is going to gain awareness of
SEC_ACE_TYPE_ACCESS_ALLOWED_CALLBACK_OBJECT and the like.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
A device has SIDs too, and a modern security token needs to know
them in order to interpret conditional expressions like
"Device_member_of".
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
384 bytes is not a strict threshold below which claims are never to be
compressed. Windows has been known to compress claims a mere 368 bytes
in size.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Windows doesn’t reject these, nor do we have any reason to do so.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is because commit f893cf85cc
changed the security token in secuirty.idl, and bumping the version
was missed.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
A security token contains the context needed to make access decisions
for a particular client, which has until now been a number of SIDs and
flags. Claims are arbitrary attributes that can be tacked onto the
security token. Typically they will arrive via a Kerberos PAC, but we
don't need to worry about that now -- only that they are stored on the
token.
The security token in [MS-DTYP] 2.5.2 is described in abstract terms
(it is not transmitted on the wire) as behaving *as if* it held claims
in three arrays of CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1 structures. We
take that suggestion literally. This is *almost* the same as storing
the [MS-ADTS] 2.2.18 claims wire structures that the claims are
presumably derived from, and doing that might seem like a small
optimisation. But we don't do that because of subtle differences and
we already need CLAIM_SECURITY_ATTRIBUTE_RELATIVE_V1 in security.idl
for resource attribute ACEs.
The three stored claim types are user claims, device claims, and local
claims. Local claims relate to local Windows accounts and are unlikely
to occur in Samba. Nevertheless we have the array there just in case.
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): Thu Sep 7 05:50:24 UTC 2023 on atb-devel-224
This will be used in Resource Attribute ACEs, and in security tokens
when security tokens become claim-aware.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
