* Current problematic cases with immutable loginuid
@ 2021-06-07 15:09 Andreas Hasenack
2021-06-07 17:49 ` Richard Guy Briggs
0 siblings, 1 reply; 2+ messages in thread
From: Andreas Hasenack @ 2021-06-07 15:09 UTC (permalink / raw)
To: Linux-audit
Hi,
I was reading up on setting loginuid immutable, and was wondering what
are the current known problematic cases.
In general, anything that requires switching a set loginuid to another
value will be blocked:
- sshd started on another port by the logged in user to debug
something, and that debug requires logging in as a different user than
the one who started it up
- container that starts up within the user's session, instead of via
dockerd/containerd, systemd, or some other already-running daemon. I
read a lengthy bug in Redhat's bugzilla about a bad interaction with
systemd's nspawn, where apparently the container is started directly,
and thus inheriting the user's loginuid, instead of being started via
a request to systemd (the daemon)
The manpage mentions "certain kinds of containers", and I assume it's
a reference to nspawn's case above.
Are there other prominent problematic situations that people have
encountered while setting loginuid immutable?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Current problematic cases with immutable loginuid
2021-06-07 15:09 Current problematic cases with immutable loginuid Andreas Hasenack
@ 2021-06-07 17:49 ` Richard Guy Briggs
0 siblings, 0 replies; 2+ messages in thread
From: Richard Guy Briggs @ 2021-06-07 17:49 UTC (permalink / raw)
To: Andreas Hasenack; +Cc: Linux-audit
On 2021-06-07 12:09, Andreas Hasenack wrote:
> Hi,
>
> I was reading up on setting loginuid immutable, and was wondering what
> are the current known problematic cases.
>
> In general, anything that requires switching a set loginuid to another
> value will be blocked:
> - sshd started on another port by the logged in user to debug
> something, and that debug requires logging in as a different user than
> the one who started it up
I could see that being an issue since that user may not have
CAP_AUDIT_CONTROL and be starting it as an unprivileged user on a port
number larger than 1024.
> - container that starts up within the user's session, instead of via
> dockerd/containerd, systemd, or some other already-running daemon. I
> read a lengthy bug in Redhat's bugzilla about a bad interaction with
> systemd's nspawn, where apparently the container is started directly,
> and thus inheriting the user's loginuid, instead of being started via
> a request to systemd (the daemon)
My understanding was that any container with systemd running as PID=1 in
a PID namespace was causing this problem. This is a known and
intentional limitation. Auditd should be able to run in the initial
user namespace not under a namespaced systemd. There should be no issue
here.
> The manpage mentions "certain kinds of containers", and I assume it's
> a reference to nspawn's case above.
>
> Are there other prominent problematic situations that people have
> encountered while setting loginuid immutable?
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-06-07 17:52 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-07 15:09 Current problematic cases with immutable loginuid Andreas Hasenack
2021-06-07 17:49 ` Richard Guy Briggs
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.