My understanding is that the auid/loginid process property is to allow the
audit system to *really* know who did things In particular it seems to be
for tracking who did things when they run su or sudo
But it seems to be trivial to spoof it
login as: paul
paul(a)192.168.111.40's password:
Last login: Fri Apr 13 13:34:26 2007 from 192.168.111.101
[paul@rhes5-wa-1 ~]$ sudo bash
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
556[root@rhes5-wa-1 ~]# echo 600 > /proc/self/loginuid
[root@rhes5-wa-1 ~]# cat /proc/self/loginuid
600[root@rhes5-wa-1 ~]# exit
[paul@rhes5-wa-1 ~]$ cat /proc/self/loginuid
556[paul@rhes5-wa-1 ~]$
I was 556 at login, after sudo i am still 556 but then as root I can now
change it to 600 and the audit log for my actions has auid=600 in it
doesnt that undermine the whole point of the login id?
Surely once it has been set it should not be possible to change it again.
I see a debate in the thread "proc_loginuid_write() checks wrong capability"
about who should be able to do this but it misses the point. It should only
be writtable if its -1 at the moment.
Otherwise it must be unconditionally rejected.
The argument for it being like it is is that root is all powerfull so they
should be allowed to do anything. But the beauty of auid is that it lets me
see who the root sudoer really is.
(BTW - my 10$ says its should be a new capability since it doesn't match
either CONTROL or WRITE, But if that's not possible then it should be
CONTROL)
Any insights gratefully received
Paul Moore