logging what root is doing

nielsk

nielsk

Hi,

new audit-requirements came up (yeah EU-GDPR and its requirement for acccountability who did when what when dealing with personal data) and now I try to figure out, how I can log what the root-user is doing, especially when an admin is doing sudo su. As I noticed certain commands like "cd" won't work with sudo when I try to enter a directory with a user that doesn't have permissions to enter it. Thus I see only sudo su as the only way to do that (or "su" for that matter). But at that moment I need to be able to tell what the root-user did. I tried using auditd but even a root:all in the audit-control-file didn't bring anything up. And accounting and lastcomm shows me the commands root ran but not the arguments. What can I do?
 
I think that you might want to take a better look into auditing. If you want to audit a specific user then you'd normally configure /etc/security/audit_user, not something in audit_control. See also audit_user(5). Although the system definitely has its limitations it should be able to log exactly what commands are being used.
 
Read the requirements on the audit trail. It probably says how and where the audit data needs to be stored. Which is a problem: If the audit data is stored on the computer itself, in a normal file on a normal file system using a normal disk, then root can modify it, making the audit not very useful, since it can't be trusted.

In the end, you need some sort of trust relationship to do an audit. At the bottom, you can trust one particularly trustworthy individual. That person has to be root. Once you decide that you can trust that human, you can simply ask them to keep a log of all their activity manually.

Or you can trust some special hardware. For example, you could use a special disk drive that has certain areas that are cryptographically configured to be writeable only once (such things exists, read the SED specification), with a special file system which allows for append-only files (I know such things have been talked about, although I don't know of any practical implementation in open source software). Then the special disk and file system have to be configured and retrieved by a specially trusted audit administrator. Now you're back to having to trust a human.
 
nielsk said:
Hi,

new audit-requirements came up (yeah EU-GDPR and its requirement for acccountability who did when what when dealing with personal data) and now I try to figure out, how I can log what the root-user is doing, especially when an admin is doing sudo su. As I noticed certain commands like "cd" won't work with sudo when I try to enter a directory with a user that doesn't have permissions to enter it. Thus I see only sudo su as the only way to do that (or "su" for that matter). But at that moment I need to be able to tell what the root-user did. I tried using auditd but even a root:all in the audit-control-file didn't bring anything up. And accounting and lastcomm shows me the commands root ran but not the arguments. What can I do?
Click to expand...

We are affected as well, as anybody within the EU, I think the whole thing is over-exaggerated, EU itself won't be able to cope, Brussels won't be ready by May, not to comment on countries like ... Greece.. Anyway, I think most important is to hire a consultant, its not so tragic as it sounds. The hardest part is with reliable auditing at the app and database level. There are products for this. Now if the shell access was indeed under GDPR and needs smth more than just /etc/security then I guess some (linux) product would be out there already covering that.
 
Change the password for root and only give a specific person that access. Configure sudo to only allow specific commands to be executed (and don't add su to that list, and disable "sudo -l" and "sudo -s" support). Enable audit support, with logging to a remote system (where you can do the append-only logging, encryption, storage, whatever, etc). Enable remote logging for syslog with similar setup. Then set a written policy along the lines of "Don't login directly as root unless absolutely required. If you do, then fill in Form X with everything that you did." That way, you CYA for legal. :)

Webmin is also good for situations like this as you can give root-like capabilities, with every command executed/link followed being logged. This is what we use to allow non-IT staff to have "admin" access to the school servers (for managing accounts, managing web filters, managing printers, and such), but giving us an audit trail we can look back at when things go sideways. Really comes in handy for those "something broke on the server, no idea why, I didn't change anything" calls where we can say "the logs tell me you broke it by doing X at such-n-such time". :)
 
The EU-GDPR does in no way require to log all server/root activity.
Basically it requires you (or the company) to keep record and document every workflow/procedure by which you gather customer data, in what way you ensure this data is kept safe and why/how/under what requirements you transmit customer data to 3rd parties (e.g. to fulfill a contract).
This documentation only has to poof your workflows and the used technologies (e.g. software) have been assessed to comply with the data protection laws.
E.g. for a contact form on your website you have to justify WHY you need to gather the specific data you are asking for, that you inform the user/customer about how this data is processed and used (-> data privacy agreement or "Datenschutzvereinbarung" in german) and how it is ensured this data reaches (only) you, how long it is stored and for what purposes it is used (and eventually handed over to other parties - if the customer/user agreed on this!).
You DON'T have to log every entry that has been made to that form, especially because this would generate even more personal data, which your don't need to fulfill your business and hence shouldn't be even collected in the first place according to the GDPR!
Again: the GDPR only requires you to document the underlying workflow to proof it complies with the privacy requirements, in no way should you collect even more personal data - if any it should lead to less customer data being gathered and stored. Best case would be that all personal data is anonymized at a very early stage, as this shortens the data trail that has to be assessed and documented.

I just got home from a lengthy presentation about this topic (I was dragged there because "I do all the network and computer stuff"), if you like we can talk a bit more via PN (in german, as I see you are a fellow countryman and this topic is littered with stupid german wording... ;) )

Edit:
Just to be on the safe side: IANAL - this only reflects what I've learned and understood from this presentation held by a legal advisor and an IT consultant from the local IHK (german "chamber of industry and commerce") and some condensed summaries about the GDPR I've read before.
 
xchris said:
I hope it was a h/ware keylogger, as secure keyboard mode on xterm isolates keystrokes.
Click to expand...

I believe it was a kernel module. I wish I remember what it was, but we are using only FreeBSD/illumos nowadays, so, it would not work. By the way, not only we had a full disclaimer at terminal login, but all operators were asked to sign a note acknowledging the logging of all input.
 
ralphbsz said:
Or you can trust some special hardware. For example, you could use a special disk drive that has certain areas that are cryptographically configured to be writeable only once (such things exists, read the SED specification) ...
Click to expand...

I notice that a port was just recently added for an open source version of a utility for SED management:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219408

It might be interesting to play with it. But, not sure how many drives ship with this capability.
 
ronaldlees said:
It might be interesting to play with it. But, not sure how many drives ship with this capability.
Click to expand...

Ship with it? A lot. It's pretty common among enterprise-grade SCSI (meaning SAS) drives.

"Interesting" to play with? Hell no. If you want to do key management right, they are seriously hard to use. To begin with: where are you going to store the keys? Not on the drive itself! Now you need to build a reliable (redundant) yet secure key server. That should keep an amateur busy for a long time.
 
phoenix said:
Enable audit support, with logging to a remote system (where you can do the append-only logging, encryption, storage, whatever, etc)
Click to expand...

Any idea how to send audit logs via syslog?

I saw this can be done for Solaris: https://docs.oracle.com/cd/E19253-01/816-4557/audittask-11/index.html
However, following audit configuration doesn't seem to be working under FreeBSD. Is there something similar to audit_syslog.so plugin for FreeBSD?


# cat /etc/security/audit_control
Code: 
#
# $FreeBSD: releng/12.0/contrib/openbsm/etc/audit_control 292432 2015-12-18 09:48:01Z brueffer $
#
dir:/var/audit
dist:off
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M
plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20;
plugin:name=audit_syslog.so;p_flags=+lo,-ss
 
You must log in or register to reply here.
Back
Top