From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH 7/7] audit: audit feature to set loginuid immutable Date: Wed, 10 Jul 2013 14:16:00 -0400 Message-ID: <1373480160.31358.1.camel@dhcp137-13.rdu.redhat.com> References: <1369411910-13777-1-git-send-email-eparis@redhat.com> <1453848.WlUzMfBVNC@x2> <51DCA20F.6020309@magitekltd.com> <1768498.01aSW39qOl@x2> <51DD7065.8080206@magitekltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51DD7065.8080206@magitekltd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wed, 2013-07-10 at 09:32 -0500, LC Bruzenak wrote: > On 07/10/2013 08:46 AM, Steve Grubb wrote: > > > > Currently its a compile time option. This means when its selected the auid is > > immutable and you have a strong assurance argument that any action by the > > subject really is the subject's account. Strong assurance may be required for > > high assurance deployments. It would be more solid standing up in court as > > well because the argument can be made that whatever action occurred can be > > attributed to the subject because there is no way to change it. Its tamper- > > proof. > That was my understanding. > > > > The change means the default policy will now allow process with > > CAP_AUDIT_CONTROL to change the auid to anything at anytime and then perform > > actions which would be attributed to another user. There is an event logged on > > setting the loginuid, so it could be considered tamper-evident. At least as > > long as the event's not filtered or erased. > This sounds dangerous. Why would we want to allow this? Immutability was first introduced in kernel 3.3. It wasn't enabled in the kernel config for Fedora until some time much later. It is not present in any enterprise distro that I know of. Before systemd immutability was not possible. If an admin logged in and restarted the sshd daemon the daemon would be running as the admin's loginuid. When a new user tried to log in via ssh it would need to change the loginuid from the admin loginuid to their new loginuid. We had to give sshd CAP_AUDIT_CONTROL in order to switch the loginuid. (ALL loginuid changes required CAP_AUDIT_CONTROL) When systemd came out I added immutability. Since restarting sshd in a systemd world is done by init, which has no loginuid, and thus the new sshd would have no loginuid. Thus a user logging in would be able to set a new loginuid without any permissions. We learned that admins, for various reasons, really do want to be able to launch daemons by hand and not via init/systemd. In particular, we know of many people who launch containers by hand which allows some form of login (usually sshd). With the current loginuid immutable code those people are UNABLE to log in inside the container. This patch series allows a privileged task (one with CAP_AUDIT_CONTROL) the ability to unset their own loginuid. I allows behavior similar to the pre 3.3 kernels. Big different being that the privilege is needed in a helper to UNSET the loginuid, not in the network facing daemon (ssh) to SET the loginuid. The series also allows the 'unsetting' feature to be disabled and locked so it cannot ever be enabled. Whew, so now we have background. Now we can talk about the tamper-proof vs tamper-evident discussion. I do not buy tamper-proof at all. If the user has CAP_AUDIT_CONTROL claiming tamper-proof-ness is a lie. They can auditctl -e0 and win. Ah, but one might retort, what is someone ran auditctl -e2. And I would retort, but good sir, if you ran auditctl -e2 to stop CAP_AUDIT_CONTROL from completely owning the box, why didn't you set the loginuid immutable first? Thus far every statement that I have seen about loginuid_immutable being necessary on the kernel command line does not stand up to scrutiny... -Eric