I was talking to Wietse Venema about SE Linux and related things. He suggested that we consider doing what the C2 pack for SunOS apparently used to do (and what presumably some module of Trusted Solaris still does) in regard to the auid. In the SunOS case it was apparently impossible to reset the auid, not even root can do so.
Of course this gives the problem of what happens when you restart sshd or crond, those programs would then be unable to set the auid. In Fedora we have gdm started from init, so restarting gdm is possible without auid issues in this regard. As we have the precedent with this daemon (which incidentally most other distributions seem to start from an /etc/init.d script) it doesn't seem unreasonable to me for "sshd -D" to also be run from init, and modifying crond to also support a -D option would not be difficult.
Of course then we have the issue of other programs such as mail servers which perform actions on behalf of users but which should not be started from init.
The next possibility that occurred to me is to have SE Linux control setting and resetting the auid. Then when the administrator starts the mail server the auid could be reset but when a mail server process is delivering mail and sets the auid it would not be able to do so. Even that seems inadequate in some ways.
Another possibility that occurred to me is to have the auid field be an append-only text field. Therefore every audit record would have the chain of UIDs used back to when things were started by the kernel. In this case you might have auid=-1:500:0:501 to indicate that the user with UID 500 logged in to the system, run su or sudo to get uid 0 (or some other method) and then transitioned to uid 501 to perform the action in question. If the program which had the action logged was part of a MTA then that might indicate the mailer daemon being started by user 500 via sudo which then delivered mail to user 501.
On Thu, Feb 09, 2006 at 10:33:25PM +1100, Russell Coker wrote:
to do (and what presumably some module of Trusted Solaris still does) in regard to the auid. In the SunOS case it was apparently impossible to reset the auid, not even root can do so.
Same with the luid on trusted Unix like old SCO.
Of course this gives the problem of what happens when you restart sshd or crond, those programs would then be unable to set the auid. In Fedora we
You ask a daemon to restart them. In the old days of course init managed it all off inittab so the problem didnt arise.
Of course then we have the issue of other programs such as mail servers which perform actions on behalf of users but which should not be started from init.
It is performing actions _for_ that user. They are if you like the "billable entity"
Hi Russell,
This discussion is probably best held on the linux-audit mail list since you are possibly suggesting changing the behavior of the audit system.
http://www.redhat.com/mailman/listinfo/linux-audit
He suggested that we consider doing what the C2 pack for SunOS apparently used to do (and what presumably some module of Trusted Solaris still does) in regard to the auid.
Why? The current design is that only entry point programs set the login uid (auid). It works per the design. I don't really understand what problem you see.
In the SunOS case it was apparently impossible to reset the auid, not even root can do so.
Setting the login uid is supposed to be protected by SE Linux policy so that only the right apps can do it.
In this whole email, you never specified what problem you see.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Thu, 2006-02-09 at 22:33 +1100, Russell Coker wrote:
Of course this gives the problem of what happens when you restart sshd or crond, those programs would then be unable to set the auid. In Fedora we have gdm started from init, so restarting gdm is possible without auid issues in this regard. As we have the precedent with this daemon (which incidentally most other distributions seem to start from an /etc/init.d script) it doesn't seem unreasonable to me for "sshd -D" to also be run from init, and modifying crond to also support a -D option would not be difficult.
This is absolutely horrible. Its bad enough I have to switch run levels just to shut down gdm, the last thing we need is more daemons run from init.
So, about that FCNewInit thing...
-
Alan Cox -
Callum Lerwick -
Russell Coker -
Steve G