From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC] TTY auditing Date: Sat, 2 Jun 2007 09:02:44 -0400 Message-ID: <200706020902.44326.sgrubb@redhat.com> References: <46609895.1050508@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <46609895.1050508@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Miloslav Trmac Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Friday 01 June 2007 18:07:17 Miloslav Trmac wrote: > Hello, > the attached patches propose a way to audit administrative commands. Thanks for working on this problem. This should close the last gap for NI= SPOM,=20 PCI, and DCID 6/3. Its important to have this capability. > Summary > ------- > A per-process "audit TTY input" attribute is added.=20 I wonder if this would be better hanging off the audit context? That's wh= ere=20 we put file names and other aux records. > Optionally, user-space applications can send advisory audit events > describing the "meaning" of the TTY input. Its nice to have that capability, but I think in practice, it will mean=20 changing a lot of apps. So, I have this feeling that we shouldn't do it. = We=20 can leave it there in case anyone wants to do that. > Fundamental limitations > ----------------------- > Only TTY input is logged, so an administrator may execute unknown code > by downloading shell scripts over the network.=20 This is fine. We just need whatever they type. > Auditing processes, not TTYs > ---------------------------- > A potential problem with is approach is unwanted auditing of TTY input > to system daemons run (or restarted) by an administrator; =C2=A0 This should be OK. There had better not be tty interaction to a daemon. I= t=20 should detach from ttys and open stdin to /dev/null. If it does that, doe= s=20 the auditing end? > if the administrator restarts an *getty daemon, all inputs to the daemo= n > would be audited. =C2=A0As a special hack, opening a TTY in a process t= hat has no > TTY currently open automatically disables the "audit TTY input" flag. > Closing the current TTY and opening another one does not really make an= y > sense in a regular application, but daemons which close all file > descriptors on startup would be handled by the hack. =C2=A0If the hack > doesn't handle a specific daemon automatically, the daemon could either > be modified to disable auditing, or its startup scripts could explicitl= y > close TTYs to activate the hack. We do not want a loophole for daemon's to change auditing. > Semantics of the logged data > ---------------------------- > As a special case, input read when the TTY is using ICANON without ECHO > is _not_ audited, to avoid storing passwords in the audit log. I think we should audit everything or this becomes the hole to issue comm= ands=20 that are not audited. The audit logs are high integrity and should be=20 trusted. > Attached code > ------------- > - a kernel patch, against a current-ish Linux tree. > - a patch against audit-1.5.3 to recognize the new netlink message type= s > - a PAM module which allows enabling/disabling TTY auditing on login > - a patch against readline-5.2 to generate advisory audit events on > =C2=A0 returned strings. =C2=A0The exact same patch can be used for the= readline > =C2=A0 copy included in bash-3.2. > > Unresolved questions: > --------------------- > The advisory audit events may be emitted by any process for which TTY > input is audited, no additional privileges are necessary. =C2=A0Is it > necessary to separately limit the rate of the generated events, or is > the current kernel rate limit sufficient? In a way, I don't like unprivileged processes having the ability to creat= e=20 events programmaticly. It could be easily used to DoS the audit system. M= aybe=20 we shouldn't worry about advisory records. > Reading and modifying the "audit TTY input" attribute using a the audit > netlink socket works, but it feels unnatural. =C2=A0Should it be done > differently (e.g. /proc, prctl ())?=20 No, I'd rather keep everything going through the same interface for many=20 reasons. SE Linux policy being one of them. > Is it enough to allow an administrative process to read/modify its > own "audit TTY input" attribute, or is it necessary to access the attri= bute > of other processes? It should be set by login processes and then be immutable. IOW, it can't = be=20 turned off. Briefly looking at the kernel patch, it should have "auid" logged in the=20 events. I'll send separate feedback on the kernel patch, though. In general, I think this is a much more thorough approach than the bash a= udit=20 patch I worked up earlier this year and more likely to meet the real need= s. Thanks, -Steve