RE: Setting loginuid for a process starting at boot
Auditctl -e wont probably go unnoticed while an inconspicuous echo probably would.
Is there a rule to track this action without overloading the system ?
Alternatively, is a post mortem analysis viable ?
I was thinking of finding process in the audit.log whose loginuid differs from
parent's loginuid.
Is there a way to extract information and reformat the result (to keep process pid ppid
loginuid for example) ?
Philippe
-----Message d'origine-----
De : Steve Grubb [mailto:sgrubb@redhat.com]
Envoyé : lundi 13 janvier 2014 23:06
À : Maupertuis Philippe
Cc : linux-audit(a)redhat.com
Objet : Re: Setting loginuid for a process starting at boot
On Monday, January 13, 2014 10:17:43 PM Maupertuis Philippe wrote:
The process listens on a network port. It receives custom commands
that are executed on the server. Only one remote host can communicate
with the host, the user identifies himself on the remote host only.
The goal is to allow the user to run the same scripts on a lot of server in one
command.
OK, then it sounds like you have an entry point daemon and it should be setting the
loginuid.
Please don't tell me it's silly or insecure or that softwares
exist to do
that in a secure way. I would like to be able to at least monitor what
happend throughthis channel. That means the listening process and all its
childs where the valuable changes to the system are made. It's why I was
thinking of setting a dedicated loginuid.
Maybe, eventually it would turn in a PAM-aware application with a proper
user authentication and my problems will be solved.
If a simple echo does the trick what is the use of audit_setloginuid or
pam_loginuid ?
They hide the implementation details in case it changes someday.
Any root script can defeat audit with a single command.
There are restrictions (fs/proc/base.c). You can only set the loginuid on
yourself.
I am gobsmacked !
I hope I missed something.
And besides, any root process can run auditctl -e 0 and disable the audit
system (unless it was marked immutable).
-Steve
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de
ses destinataires. Il peut également être protégé par le secret professionnel. Si vous
recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de
le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la
responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien
que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout
virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne
saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in error, please notify
the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Worldline liability cannot be triggered for the message content. Although the sender
endeavours to maintain a computer virus-free network, the sender does not warrant that
this transmission is virus-free and will not be liable for any damages resulting from any
virus transmitted.