auid

[Russell Coker]

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

[Alan Cox]

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"

[Steve G]

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

[Callum Lerwick]

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...