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. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list