One of the record classes available in PAM SC is the SUDO class. By definition, the syntax of a record in this class is
newres SUDO <Name_of_record> data('<command>;prohibited-values; permitted-values ')
for instance
er sudo traceroute defaccess(none) owner(nobody) audit(all) targuid(root) comment('/bin/ping;;')
However the question is whether it is possible to specify a list of multiple parameters, including wildcards.
That is whether a rule like
er sudo chown defaccess(none) owner(nobody) audit(all) targuid(root) comment('/usr/bin/chown;;*/test */test2 ')
auth sudo chown uid(test) access(x)
is possible and so if one runs
/usr/bin/chown mydir/test myotherdir/test2
as user test, it will allow access chown to act on both mydir/test and myotherdir/test2
PAMSC 14.1
Behaviour sample that seems acting incorrect
Using * (Current state):
Data: /usr/bin/chown;;* /apps/users/<useraccount>
/*
sesudo chown_test <useraccount>
/apps/users/<user>/prueba -> Permitted (Unexpected)
Using $u (Proposed state):
Data: /usr/bin/chown;;$u /apps/users/<useraccount>/*
sesudo chown_test <useraccount>
/apps/users/<user>/prueba -> Denied (Correct)
The system clearly possesses the capability to validate parameters positionally, but the standard * wildcard fails to enforce the path restriction in the second parameter position, whereas the $u token succeeds in forcing this validation.
To be able to specify multiple positional parameters it is necessary to separate them using the pipe (|)
For example, the format should be:
data('/usr/bin/chown;;param1|param2|param3')
er sudo traceroute defaccess(none) owner(nobody) audit(all) targuid(root) comment('/usr/bin/chown;;*/test|*/test2 ')
In each parameter, specified in the positional list, the * will act as a wildcard, as expected. So this corrected sudo record would allow you to successfully run as user test the specified command
/usr/bin/chown mydir/test myotherdir/test2
When the separator is used, the validation works as expected.