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 <[email protected]> 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 [email protected] https://listman.redhat.com/mailman/listinfo/linux-audit
