* Setting loginuid for a process starting at boot
@ 2014-01-12 22:00 Maupertuis Philippe
2014-01-13 20:12 ` Eric Paris
0 siblings, 1 reply; 9+ messages in thread
From: Maupertuis Philippe @ 2014-01-12 22:00 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1436 bytes --]
Hi,
I want to monitor a process which starts at boot.
I would like to assign it a specific loginuid for that purpose.
What is the best way to do that ?
Regards
Philippe
________________________________
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.
[-- Attachment #1.2: Type: text/html, Size: 3704 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Setting loginuid for a process starting at boot
2014-01-12 22:00 Setting loginuid for a process starting at boot Maupertuis Philippe
@ 2014-01-13 20:12 ` Eric Paris
2014-01-13 20:16 ` Steve Grubb
0 siblings, 1 reply; 9+ messages in thread
From: Eric Paris @ 2014-01-13 20:12 UTC (permalink / raw)
To: Maupertuis Philippe; +Cc: linux-audit@redhat.com
On Sun, 2014-01-12 at 23:00 +0100, Maupertuis Philippe wrote:
> Hi,
>
> I want to monitor a process which starts at boot.
>
> I would like to assign it a specific loginuid for that purpose.
>
> What is the best way to do that ?
Have the init script echo a value into /proc/self/loginuid ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Setting loginuid for a process starting at boot
2014-01-13 20:12 ` Eric Paris
@ 2014-01-13 20:16 ` Steve Grubb
2014-01-13 21:17 ` RE : " Maupertuis Philippe
0 siblings, 1 reply; 9+ messages in thread
From: Steve Grubb @ 2014-01-13 20:16 UTC (permalink / raw)
To: linux-audit; +Cc: Maupertuis Philippe
On Monday, January 13, 2014 03:12:55 PM Eric Paris wrote:
> On Sun, 2014-01-12 at 23:00 +0100, Maupertuis Philippe wrote:
> > Hi,
> >
> > I want to monitor a process which starts at boot.
> >
> > I would like to assign it a specific loginuid for that purpose.
> >
> > What is the best way to do that ?
>
> Have the init script echo a value into /proc/self/loginuid ?
The loginuid is supposed to be used only for real user sessions. The daemon
would not normally qualify as a user session. I suspect that this is needed
because we have no way to audit by process name. I suspect that is the real
issue that leads to needing to use the loginuid for something it was not
intended for.
-Steve
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE : Setting loginuid for a process starting at boot
2014-01-13 20:16 ` Steve Grubb
@ 2014-01-13 21:17 ` Maupertuis Philippe
2014-01-13 22:05 ` Steve Grubb
0 siblings, 1 reply; 9+ messages in thread
From: Maupertuis Philippe @ 2014-01-13 21:17 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
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.
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 ?
Any root script can defeat audit with a single command.
I am gobsmacked !
I hope I missed something.
Philippe
________________________________________
De : Steve Grubb [sgrubb@redhat.com]
Date d'envoi : lundi 13 janvier 2014 21:16
À : linux-audit@redhat.com
Cc : Eric Paris; Maupertuis Philippe
Objet : Re: Setting loginuid for a process starting at boot
On Monday, January 13, 2014 03:12:55 PM Eric Paris wrote:
> On Sun, 2014-01-12 at 23:00 +0100, Maupertuis Philippe wrote:
> > Hi,
> >
> > I want to monitor a process which starts at boot.
> >
> > I would like to assign it a specific loginuid for that purpose.
> >
> > What is the best way to do that ?
>
> Have the init script echo a value into /proc/self/loginuid ?
The loginuid is supposed to be used only for real user sessions. The daemon
would not normally qualify as a user session. I suspect that this is needed
because we have no way to audit by process name. I suspect that is the real
issue that leads to needing to use the loginuid for something it was not
intended for.
-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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Setting loginuid for a process starting at boot
2014-01-13 21:17 ` RE : " Maupertuis Philippe
@ 2014-01-13 22:05 ` Steve Grubb
2014-01-14 13:13 ` Maupertuis Philippe
0 siblings, 1 reply; 9+ messages in thread
From: Steve Grubb @ 2014-01-13 22:05 UTC (permalink / raw)
To: Maupertuis Philippe; +Cc: linux-audit@redhat.com
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Setting loginuid for a process starting at boot
2014-01-13 22:05 ` Steve Grubb
@ 2014-01-14 13:13 ` Maupertuis Philippe
2014-01-14 14:33 ` Steve Grubb
0 siblings, 1 reply; 9+ messages in thread
From: Maupertuis Philippe @ 2014-01-14 13:13 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
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@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Setting loginuid for a process starting at boot
2014-01-14 13:13 ` Maupertuis Philippe
@ 2014-01-14 14:33 ` Steve Grubb
2014-01-14 15:55 ` Maupertuis Philippe
0 siblings, 1 reply; 9+ messages in thread
From: Steve Grubb @ 2014-01-14 14:33 UTC (permalink / raw)
To: Maupertuis Philippe; +Cc: linux-audit@redhat.com
On Tuesday, January 14, 2014 02:13:45 PM Maupertuis Philippe wrote:
> Auditctl -e wont probably go unnoticed while an inconspicuous echo probably
> would.
Both are auditable events as required by common criteria. Changes to auditing
must produce an event as well as the assignment of loginuids. This is
automatic and not caused by a rule.
> Is there a rule to track this action without overloading the system?
Changes to audit state are auditable events. You can test this yourself with
auditctl and ausearch.
> Alternatively, is a post mortem analysis viable ?
yes.
> 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) ?
You can write a utility using the auparse library to do anything you want it
to do.
https://fedorahosted.org/audit/browser/trunk/tools/aulastlog/aulastlog.c
The aulastlog program is probably a decent starting point to create something
like this. Instead of keeping uid, you'd be keeping pids and some attributes
of them. My guess is that you'll have long running processes that are not in
the logs and you'll have some unknowns.
-Steve
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Setting loginuid for a process starting at boot
2014-01-14 14:33 ` Steve Grubb
@ 2014-01-14 15:55 ` Maupertuis Philippe
2014-01-14 16:15 ` Steve Grubb
0 siblings, 1 reply; 9+ messages in thread
From: Maupertuis Philippe @ 2014-01-14 15:55 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
Thank you so much for your very valuable answers.
After playing around, I found that the assignment of loginuid produces a login type message (I could have guess)
Where can I find the description and the trigger of all messages types if such a documentation exists ?
Philippe
-----Message d'origine-----
De : Steve Grubb [mailto:sgrubb@redhat.com]
Envoyé : mardi 14 janvier 2014 15:34
À : Maupertuis Philippe
Cc : linux-audit@redhat.com
Objet : Re: Setting loginuid for a process starting at boot
On Tuesday, January 14, 2014 02:13:45 PM Maupertuis Philippe wrote:
> Auditctl -e wont probably go unnoticed while an inconspicuous echo
> probably would.
Both are auditable events as required by common criteria. Changes to auditing must produce an event as well as the assignment of loginuids. This is automatic and not caused by a rule.
> Is there a rule to track this action without overloading the system?
Changes to audit state are auditable events. You can test this yourself with auditctl and ausearch.
> Alternatively, is a post mortem analysis viable ?
yes.
> 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) ?
You can write a utility using the auparse library to do anything you want it
to do.
https://fedorahosted.org/audit/browser/trunk/tools/aulastlog/aulastlog.c
The aulastlog program is probably a decent starting point to create something
like this. Instead of keeping uid, you'd be keeping pids and some attributes
of them. My guess is that you'll have long running processes that are not in
the logs and you'll have some unknowns.
-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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Setting loginuid for a process starting at boot
2014-01-14 15:55 ` Maupertuis Philippe
@ 2014-01-14 16:15 ` Steve Grubb
0 siblings, 0 replies; 9+ messages in thread
From: Steve Grubb @ 2014-01-14 16:15 UTC (permalink / raw)
To: Maupertuis Philippe; +Cc: linux-audit@redhat.com
On Tuesday, January 14, 2014 04:55:30 PM Maupertuis Philippe wrote:
> Where can I find the description and the trigger of all messages types if
> such a documentation exists ?
To some extent, the documentation is in the header files. They describe what
the intended use is for the event record types.
https://fedorahosted.org/audit/browser/trunk/lib/libaudit.h#L40
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/uapi/linux/audit.h?id=refs/tags/v3.12.7#n30
As for what triggers them, it can mostly be deduced from the event's type.
However, some user space apps that do the same thing as others may not
have been updated to do auditing and various distributions may or may not
enable the auditing at build time. So, the user space support varies.
-Steve
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-01-14 16:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-12 22:00 Setting loginuid for a process starting at boot Maupertuis Philippe
2014-01-13 20:12 ` Eric Paris
2014-01-13 20:16 ` Steve Grubb
2014-01-13 21:17 ` RE : " Maupertuis Philippe
2014-01-13 22:05 ` Steve Grubb
2014-01-14 13:13 ` Maupertuis Philippe
2014-01-14 14:33 ` Steve Grubb
2014-01-14 15:55 ` Maupertuis Philippe
2014-01-14 16:15 ` Steve Grubb
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).