Create a root read-only Role for Auditors

Showing results for 
Search instead for 
Do you mean 
Reply
Participant III
Posts: 7
Registered: ‎10-13-2014
#1 of 9 2,160
Accepted Solution

Create a root read-only Role for Auditors

Experts - I’d like to create a Linux/Unix read-only-root role for Auditors, InfoSec and Tech Ops, so they can examine a system without risk of breaking anything.

  • I've looked at using Centrify Command Attributes, but I don't think "(dis)allow nested command execution" will help.
  • Using Centrify (or sudo), we can grant the privileges to run some commands as root, e.g. ls, cat, cksum and tail –f
  • I don’t want to allow root privileges for e.g. find, view or more/less, as they can be used to modify a system

 

Creating the Centrify Role is easy; Making it usable is harder:

  • `sudo cat filename |less` would work fine – the `cat` is run as root, the `less` as the unprivileged user. A little script utility called something like “Auditors_less” would remove the need to remember the syntax.
  • `dzdo cat filename > ~/my_copy_of_filename` would work for the same reason, and give them a local copy to work with. Call it “Auditors_cp” or just “Acp 
  • (Note that `cat {binary_file} |cksum` seems to work anyway)
  • Replacing the functionality of `find` is trickier. The output of `find` gives the full path to a file. `find` also allows you to select on ownership, permissions etc., but that part could be replaced by `dzdo ls -l |grep {pattern}`

 

So a scriptlet that takes a starting directory as input and produces output in the form

/path/to/file     ls –l found_file

would be fine, as grep can filter the output.

 

I’ve found similar questions on formatting `ls` output on stackoverflow.com, but no usable answers – general opinion seems to be “Just use `find`”, e.g.

https://stackoverflow.com/questions/1767384/ls-command-how-can-i-get-a-recursive-full-path-listing-o...

 

Update: The following tweak of the stackoverflow awk parser works quite well for the use cases I found and produces output suitable for filtering

# Oddities on AIX and HP-UX - it skips files on the top level directory

 

cat ls-find.sh
dzdo ls -1aR $DIR | grep -v "\.$" |awk -F"\n" '
/:$/&&DIRFLAG{PATH=$0;DIRFLAG=0}
/:$/&&!DIRFLAG{sub(/:$/,"");PATH=$0;DIRFLAG=1;next}
NF&&DIRFLAG{$NF=PATH"/"$NF; print $0 }' |sort |xargs -d "\n" dzdo ls -ld


./ls-find.sh /home/tfewster |grep card_scan
drwxr-x---  5 tfewster   tfewster       4096 Sep 22 16:38 /home/tfewster/card_scan
-rwxr-x---  1 tfewster   tfewster          6 Sep 22 16:38 /home/tfewster/card_scan/file0
drwxr-x---  2 root       root           4096 Sep 22 16:38 /home/tfewster/card_scan/subdir1
-rw-r-----  1 root       root              6 Sep 22 16:38 /home/tfewster/card_scan/subdir1/secret_file1
drwxr-x---  2 root       root           4096 Sep 22 16:39 /home/tfewster/card_scan/subdir2
-rw-r-----  1 root       root              4 Sep 22 16:39 /home/tfewster/card_scan/subdir2/secret_file2

 

Any ideas to improve this and make it more portable?

 

Or any further ideas? This would be a basic, portable toolkit for auditors to carry around and build on as desired, nothing to be configured or preinstalled beforehand apart from the Centrify/sudo rights.

Centrify Guru I
Posts: 2,194
Registered: ‎07-26-2012
#2 of 9 2,150

Re: Create a root read-only Role for Auditors

@Evil_Tim,

 

Welcome back.

 

Can we step back a bit and if you don't mind describing (as statements) what auditors are supposed to do?

Looks like you are looking to give them what they need, but make sure they don't make any changes.  In my experience, in both UNIX-like systems or Windows is to keep things simple.

 

E.g.

  • They should be able to inspect the syslog  (e.g. tail /var/log/messages)
  • They should be able to run (as root) the audit tool named: yadayada.sh

This way we don't get to try to correct your implementation details if the original requirements don't really need them.

 

As far as them "breaking things" my advice is that you combine least access (e.g. just what I described above) with understanding that their tools are not run with a "fix" option (because most likely this requires testing/change control).

 

If you are using our auditing and monitoring services, you can have the role be audited and if you've enabled file monitoring, any folder under /etc/ will be monitored for any changes.  This way you can establish responsibility quickly and efficiently, plus you have the ability to roll-back any changes.

 

R.P

 

 

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant III
Posts: 7
Registered: ‎10-13-2014
#3 of 9 2,145

Re: Create a root read-only Role for Auditors

Hi Robertson - Sorry, I jumped ahead there. Yes, an Auditor should be able to look at any file on a Unix/Linux system from the command line, but not be able to make any changes. Typical tasks would include:

- Examine ownership, permissions and contents of configuration files in /etc.
- Examine ownership, permissions and contents of log files.
These can be achieved by granting them the right to run `ls`, `cat` and `tail` and other "safe" commands as root.

- Scan the filesystems for files and directories that are globally writable.
This is always done using `find`.  However, `find` has a -exec option, which allows you to execute other commands, e.g. remove a file. But using `ls -R` would make it hard to interpret the results due to the output format.


So the initial question is if we can allow an Auditor to run `find` as root, but prevent them making any changes.
Alternatively, we can use `ls -R` but manipulate the output so it shows the full path to a file in a "nice" way, using a wrapper script as shown in the original post

Unfortunately we don't use Centrify auditing and monitoring, so I'm focusing on prevention.

I posted this on the Community forum to see if I was missing something in Centrify, or anyone else had found a way to achieve the same goal (or might benefit from seeing the discussion, or even develop it further). But not a problem, I can keep working on it.

Centrify Guru I
Posts: 2,194
Registered: ‎07-26-2012
#4 of 9 2,127

Re: Create a root read-only Role for Auditors

@Evil_Tim,

 

Looks like giving him a "login-like" role without a restricted shell will solve most of the problem.

Let me engage one of our leads from PS on the find  topic.  You have a way to prevent nested command execution, but I'm not sure if it will be enough.

 

You could though have the functions split in two.  Have a regular user role for the mundane ls,cat,more things, but when he needs to use the find, you can grant a temporary role.

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Advisor I
Posts: 53
Registered: ‎09-16-2014
#5 of 9 2,117

Re: Create a root read-only Role for Auditors

Tim,

 

If you just want to allow them to find world-writable files, then you could add a sudo rule that says they can run:

 

find / -perm -2 -ls

 

(to find files and directories), or to restrict it to just files:

 

find / -type f -perm -2 -ls

 

Or, if you have multiple filesystems and don't want them traversing all of them at once, consider a wrapper script that accepts a single parameter, indicating the starting point for the find:

 

#!/bin/sh

if [ "$#" -ne 1 ]
then
  echo Usage
exit 1
fi

if [ ! -d "$1" ]
then
  echo Failure
exit 2
fi

find "$1" -perm -2 -ls

Centrify Advisor I
Posts: 42
Registered: ‎02-19-2014
#6 of 9 2,108

Re: Create a root read-only Role for Auditors

You might need to write a wrapper script with menu item to execute certain commands. Then lock down the script so they can't edit it. Then use DirectAuthorize to allow this script and to be run as root.
Participant III
Posts: 7
Registered: ‎10-13-2014
#7 of 9 2,105

Re: Create a root read-only Role for Auditors

Thanks tchariya - That's brilliant, you don't even need a menu - a find.sh wrapper script could pass parameters to `find` but just remove dangerous Actions such as -delete or -exec. So the Auditors are free to construct almost any `find` syntax themselves. If only I'd asked here weeks ago!


It should be easy to make it work on bash, ksh (AIX) and posix-sh (HP-UX) too. I'll play with that tomorrow, or enlist a shell-scripting/regexp guru, and post the results in case it helps/inspires anyone else.

e.g.

cat /usr/bin/find.sh

echo "Usage: dzdo find.sh [options] [path...] [expression]"

echo "Pass safe parameters to 'find' to be executed as root"

echo "Note, unsafe Actions in 'find' such as -remove and -exec are not passed"

echo "Special characters like double or single quotes might not work"

# sed is inefficient compared to shell Parameter Expansion, but simpleand portable

PASSPARS=`echo $@ | sed -e 's/-remove[ $]//g'`

find ${PASSPARS}



The tiny downside is that the find.sh script has to be distributed to all systems first (or installed at the same time as the Centrify Agent) rather than being defined in the AD Role or copied over by the Auditor as needed. But that's a tiny price to pay for the flexibility

Centrify Guru I
Posts: 2,194
Registered: ‎07-26-2012
#8 of 9 2,032

Re: Create a root read-only Role for Auditors

[ Edited ]

@Evil_Tim,

 

"The tiny downside is that the find.sh script has to be distributed to all systems first (or installed at the same time as the Centrify Agent) rather than being defined in the AD Role or copied over by the Auditor as needed. But that's a tiny price to pay for the flexibility" 

 

We've got you covered:  use the "Copy files" GPO

docs:  https://docs.centrify.com/en/css/2017.2-html/index.html#page/Group_policies/Common_UNIX_settings.2.h...

blog: http://centrifying.blogspot.com/2014/09/utilities-powerful-copy-files-gpo.html

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant III
Posts: 7
Registered: ‎10-13-2014
#9 of 9 2,030

Re: Create a root read-only Role for Auditors

That is awesome, and I can see a lot of other uses for it. My only excuse for not finding this out for myself is that I'm primarily a Unix guy, but I have colleagues who can help me out with AD Group Policy