RE: (no subject)
Aha - I see that there is an audit event for the auid change. Thats good
enough for me - thanks
I still have a couple of questions
A) sometimes as root I echo to /proc/self/loginuid and it is ignored. Why?
There is no error message
B) always if I echo to /proc... as non root it is ignored (as it should be)
but no message is generated; shouldn't it say EPERM?
C) I put pam_loginuid in my gdm pam config but my xterm windows still have
-1 in loginuid (I have rebooted)
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Friday, April 20, 2007 4:32 PM
To: linux-audit(a)redhat.com
Cc: paul moore
Subject: Re: (no subject)
On Friday 20 April 2007 18:13:17 paul moore wrote:
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
Yep.
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
But you will generate an audit message right here saying that you changed
the loginuid. While its not protection, it doesn't quietly let that occur.
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?
There should still be a trail showing that you changed it.
Surely once it has been set it should not be possible to change it
again.
I think there are 1 or 2 daemons that count on that.
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.
Except in the case where daemons are changing loginuid temporarily to record
the fact that its doing something on behalf of a user. For example, I think
postfix may do this when delivering email and reading the dot files.
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.
But there is a problem here...if you strip the CAP_AUDIT_CONTROL bit and and
admin does a restart of sshd, sshd will not be able to set it either. If you
only allow setting auid if its non-zero, how do you restart a service like
sshd since it will inherit the loginuid? The only option is to reboot the
machine, so forget about rpm upgrades.
I really think the answer is to protect this with SE Linux policy...but
there is a problem. I think that by setting loginuid by the proc filesystem
we won't be able to have a SE Linux type that is distinct for loginuid
without changing things in the kernel. Then you also have to worry about
descriptors being held open across forks. Not to mention, you have to do a
open(), write(), close() for each setting of loginuid.
So I think the best solution is to make a syscall for setting the loginuid
that SE Linux can protect with a distinct type. Then we can say things like
local_login_t is allowed setloginuid_t.
(BTW - my 10$ says its should be a new capability since it
doesn't
match either CONTROL or WRITE,
I've been saying that for a while too. I think it is distinct in the same
way that chown is different than unlink. Changing the loginuid is only 1
attribute in the event. CAP_AUDIT_CONTROL on the otherhand allows you to
delete rules. So you change whether or not the event even was recorded as
opposed to who to blame.
But one thing that does help is deleting the rules is done via netlink
interface, which SE Linux does control. So, policy can be written that
disallows anything except auditctl_t from writing to netlink, and policy can
be written saying who can run auditctl.
-Steve