|
Description
|
A customer wants to be able to allow a special user account, msduser, to scp the audit trail file from /var/audit to another system. This user account is also used for other special tasks.
The customer tried to set an ACL on the /var/audit directory, but the user still couldn't gain access to the audit trail file. I explained that this was because the audit trail file has no group permission and is created with mode 600.
I found RFE 4156198 which described the same issue, but the RFE was closed with the reason stated that Solaris 8 introduced role based access control which solves this issue.
On this basis I proposed the following two workarounds, both of which were rejected by the customer. The customer is using a different workaround with cron, but is not satisfied with that either.
Proposed workaround 1
------------
I found in the auth_attr file there is an authorisation solaris.auth.read, but looking through the source it doesn't seem to be implemented, unlike for example solaris.system.date
There is however a profile, Audit Review, that could be assigned to a user to allow them to run the auditreduce, praudit and auditstat commands in a priveleged way.
Therefore, I added the following entry to /etc/user_attr :
msduser::::type=normal;profiles=Audit Review,All
And I changed my msduser's login shell to be pfksh by updating /etc/passwd e.g:
msduser:x:667:1::/export/home/msduser:/bin/pfksh
So what should happen is that when msduser logs in and tries to run the praudit command against the audit trail, then the shell should check the profile and then use pfexec to run praudit with euid=0.
Indeed it does, but praudit still wasn't able to read the file, as shown by truss.
What I found was that for some reason euid=0 is not sufficient. For praudit to read the audit trail it needs uid=0. I updated /etc/security/exec_attr as follows and it then worked:
Audit Review:suser:cmd:::/usr/sbin/praudit:uid=0
Proposed workaround 2
------------
Here's a new suggested config based on RBAC and ssh.
/etc/passwd
msduser:x:667:1::/export/home/msduser:/bin/pfksh
"/etc/user_attr"
msduser::::type=normal;profiles=Special cat,All
"/etc/security/exec_attr"
Special cat:suser:cmd:::/usr/bin/cat:uid=0
"prof_attr"
Special cat:::Execute cat as root :
The above enables msduser to run the cat command as root. So in principle msduser could look at any file on the system.
But if you set up an ssh key for msduser, you can restrict the user to running a particular command when they try to ssh on:
/export/home/msduser/.ssh/authorized_keys
command="/usr/bin/cat /var/audit/$SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC1yc2EA
AAABIwAAAIEA7vRasUK8WSOVLu80mMI+Kt+pTNkonvI9qKmIPiAnX+Gz5qksWpvHHYTvp9DKYH2Ct7CC
bA3fTYKeTeAEhPkoVfdFNOVP4aBtEbZCFmduWGtVtzKMu9ikjNbiGrK/RdzAjcUvh4V8cAcF91XpOWKD
zSqxkLuoiBJcFh+DUXH2+M8= msduser@sigourney
Then on the client as msduser:
ssh squid-test 20050408103135.not_terminated.squid-test > local_trail_copy
So when msduser tries to ssh on, the sshd runs the command= line from the keyfile then exits.
We specify that the command is cat /var/audit/$SSH_ORIGINAL_COMMAND , where $SSH_ORIGINAL_COMMAND is the argument passed with the client ssh command line, in this case the name of the audit file thats required. We then redirect the output of cat to a local file 'local_trail_copy'.
Customer comments
-----------------
The customer ejected workaround 1 as:
"I had already considered the possibility of using RBAC for this user to access the files, however the account msduser only needs to be able to read the raw binary audit files to scp them off the system back into our internal network for offline analysis and archiving, so giving this account full RBAC priveleges to manage the audit daemon and inspect the files will be in breach of the tight security requirements for this host, which is a public facing internet web server. This is why I chose to simply limit the ability of this account to read-only access to the binary files by using setfacl defaults on the audit log directory, hence my original problem of the fact that when audit -n creates a new log file it ignores the default ACLs defined for the audit log directory."
In response to workaround 2:
"Unfortunately the limitations on the msduser account that this idea enforces will prevent this account from doing anything but use the cat command. (Or whatever substitute command is set to be used when the ssh session is initiated.) This account needs to be able to do other things when connected to the audited host, like collect file listings, remove certain types of (unrelated) files etc.
Like I said at the beginning, all we want to do is set the read-only limitation of the audit log directory without having to change anything about the msduser account priveledges.
My current (rather kludgy) work-around for this problem caused by auditd overriding the default ACLs is the following root crontab entry:
4,9,14,19,24,29,34,39,44,49,54,59 * * * * getfacl /opt/audit/.aclsrc | setfacl -f - /opt/audit/*not_terminated*
- where the file .aclsrc is just a static zero byte file touched by root after the default ACLs were set for the directory.
A cronjob on an internal facing system is using scp to pick up the current copy of the audit log 1 minute after the permissions are set (5,10,15 etc.) "
xxxxx@xxxxx.com 2005-04-18 10:44:36 GMT
|