PAMSC 14.1 is it possible to specify a list of multiple parameters, including wildcards.
search cancel

PAMSC 14.1 is it possible to specify a list of multiple parameters, including wildcards.

book

Article ID: 439242

calendar_today

Updated On:

Products

CA Privileged Access Manager - Server Control (PAMSC)

Issue/Introduction

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

Environment

PAMSC 14.1

Cause

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.

Resolution

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.