On 2019-11-01 11:13, Steve Grubb wrote:

On Friday, November 1, 2019 11:09:27 AM EDT Richard Guy Briggs wrote:

quoted

On 2019-10-31 10:50, Steve Grubb wrote:

quoted

Hello,

TLDR;  I see a lot of benefit to switching away from procfs for setting
auid & sessionid.

On Wednesday, October 30, 2019 6:03:20 PM EDT Richard Guy Briggs wrote:

quoted

quoted

Also, for the record, removing the audit loginuid from procfs is not
something to take lightly, if at all; like it or not, it's part of
the
kernel API.

It can also be used by tools to iterate processes related to one user or
session. I use this in my Intrusion Prevention System which will land in
audit user space at some point in the future.

quoted

Oh, I'm quite aware of how important this change is and it was
discussed
with Steve Grubb who saw the concern and value of considering such a
disruptive change.

Actually, I advocated for syscall. I think the gist of Eric's idea was
that / proc is the intersection of many nasty problems. By relying on
it, you can't simplify the API to reduce the complexity. Almost no
program actually needs access to /proc. ps does. But almost everything
else is happy without it. For example, when you setup chroot jails, you
may have to add /dev/random or / dev/null, but almost never /proc. What
does force you to add /proc is any entry point daemon like sshd because
it needs to set the loginuid. If we switch away from /proc, then sshd or
crond will no longer /require/ procfs to be available which again
simplifies the system design.

quoted

Removing proc support for auid/ses would be a
long-term deprecation if accepted.

It might need to just be turned into readonly for a while. But then
again,
perhaps auid and session should be part of /proc/<pid>/status? Maybe this
can be done independently and ahead of the container work so there is a
migration path for things that read auid or session. TBH, maybe this
should have been done from the beginning.

How about making loginuid/contid/capcontid writable only via netlink but
still provide the /proc interface for reading?  Deprecation of proc can
be left as a decision for later.  This way sshd/crond/getty don't need
/proc, but the info is still there for tools that want to read it.

This also sounds good to me. But I still think loginuid and audit sessionid 
should get written in /proc/<pid>/status so that all process information is 
consolidated in one place.

I don't have a problem adding auid/sessionid to /proc/<pid>/status with
other related information, but it is disruptive to deprecate the
existing interface which could be a seperate step.

-Steve

- RGB

--
Richard Guy Briggs [off-list ref]
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