Alan T. DeKok [Fri, 21 Jul 2023 18:40:14 +0000 (14:40 -0400)]
add and support suppress_secrets
the default is to not suppress secrets. Printing secrets is
suppressed if it's running as "-X" AND the configuration file
says to suppress them. Otherwise the secrets are printed.
this behavior means that for most configurations, administrators
can see (and compare) the user passwords. However, if the admins
want to suppress secrets, they can do so in their local
configuration.
Alan T. DeKok [Fri, 21 Jul 2023 17:41:54 +0000 (13:41 -0400)]
define and use fr_vasprintf_secure()
which escapes / omits the contents of any value-box which is
marked "secret".
Note that we _cannot_ do this omission in fr_value_box_print(),
as that function may be used multiple times internally. For example,
converting a clear-text password to CHAP via an MD5 xlat. Those
values should be passed through unchanged.
As a result, we can only omit secrets in a new function, which can
then be used in debug / log functions which are known to be sent
to the admin.
There are still some pieces missing.
%pM prints a value-box list, and the fr_value_box_list_aprint()
function does not take a flag for printing secrets (or not).
%pP prints a pair, and the fr_pair_aprint() function also does not
take a flag for printing secrets.
The configuration files store data in CONF_PAIRs, which don't use
value-boxes. So any shared secret is still printed in debug mode.
Alan T. DeKok [Thu, 20 Jul 2023 13:17:01 +0000 (09:17 -0400)]
add and use "safe" fields for LDAP and SQL
which means that if we escape data once, it is not escaped again.
For SQL, the escape function is tracked per driver. So you can't
escape something for MySQL, and then later use it for PostgreSQL
without that _also_ being escaped.
Alan T. DeKok [Thu, 20 Jul 2023 12:39:50 +0000 (08:39 -0400)]
"safe" values can still be tainted.
Users of that data who understand this particular value of the "safe"
flagmar can then ignore the "tainted" flag, and use the value as if it
was untainted. Every other user of the data must still treat it as
tainted.
Alan T. DeKok [Thu, 20 Jul 2023 12:13:03 +0000 (08:13 -0400)]
fr_value_box_alloc() does not need to take a "tainted" flag
a bare box is not tainted. In the few cases where the data is
tainted, it is copied from a tainted source via fr_value_box_copy(),
which also copies the tainted flag
Alan T. DeKok [Thu, 20 Jul 2023 11:49:41 +0000 (07:49 -0400)]
add fr_box() generic
which only works for some leaf types, as there string / octets
types need also to deal with length and talloc issues. Other types
like ipaddr need to check the contents of the source.
Alan T. DeKok [Mon, 17 Jul 2023 18:13:16 +0000 (14:13 -0400)]
change vp->da->type to vp->vp_type
not only is it friendlier to cache locality, it's more correct
because of things like FR_TYPE_COMBO_IPADDR, where the realized
vp->vp_type is different from the theoretical da->type
Alan T. DeKok [Fri, 14 Jul 2023 13:27:36 +0000 (09:27 -0400)]
add parse_new_conditions migration flag
and set it to "true" by default. So that the condition tests
will all be run through both the old fr_cond_tokenize() function,
and the new xlat_tokenize_condition() function.
James Jones [Thu, 13 Jul 2023 13:49:11 +0000 (08:49 -0500)]
Rewrite length check so coverity will recognize it (CID #1445221)
As the result of byte-swapping, coverity considers it tainted. It
appears that coverity only recognizes comparisons with the alleged
tainted value on the LHS as validation, so we rewrite the check
as an equivalent chack that coverity wil recognize.
It's probably simplest to just allow the first syntax. It's
redundant, but not wrong.
We then need to update the tokenizer to walk over the condition,
and ensure that the only attribute used in the condition is the
leaf attribute which we are checking.
* the tests are for conditions, but we do want to allow filtering
on group attributes:
&TLS-Certificate[&Common-Name == 'foo']
but the conditions don't allow comparisons on groups:
&TLS-Certificate == ...
So it makes sense to forbid
&TLS-Certificate[&Common-Name == 'foo'] == ...
until such time as we do allow conditions on groups.
* tmpl_dcursor now has an assertion if you try to use conditions
in filters. We still need to write the run-time evaluation code
which checks if the condition matches.
Nick Porter [Tue, 11 Jul 2023 13:52:49 +0000 (14:52 +0100)]
Check TACACS authentication type using pair
The packet available here has an encrypted body - so
packet->authen_start does not point at the bytes that make up the start
of an authentication packet body.