From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miloslav Trmac Subject: Re: [RFC] TTY auditing Date: Sat, 02 Jun 2007 15:25:49 +0200 Message-ID: <46616FDD.4000406@redhat.com> References: <46609895.1050508@redhat.com> <200706020902.44326.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200706020902.44326.sgrubb@redhat.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: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Steve Grubb napsal(a): >> Summary >> ------- >> A per-process "audit TTY input" attribute is added. > I wonder if this would be better hanging off the audit context? That's where > we put file names and other aux records. The audit context is per-thread. Does it make sense to have different TTY audit settings for different threads within a process? >> 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 > changing a lot of apps. So, I have this feeling that we shouldn't do it. We > can leave it there in case anyone wants to do that. It is optional, input characters are still logged if advisory events are not created; it can be added to applications as the need arises. On the other hand, I think it really is necessary for shells - system administrators tend to use the command-line completion, editing and history expansion extensively, and it may be very hard to reconstruct the original command line from the TTY log alone. >> 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; > This should be OK. There had better not be tty interaction to a daemon. It > should detach from ttys and open stdin to /dev/null. If it does that, does > the auditing end? No, the "audit TTY input" flag is still set, even though it doesn't affect anything. But if the deamon detaches from TTys and _then_ opens any TTY, the hack triggers. >> if the administrator restarts an *getty daemon, all inputs to the daemon >> would be audited. As a special hack, opening a TTY in a process that has no >> TTY currently open automatically disables the "audit TTY input" flag. >> Closing the current TTY and opening another one does not really make any >> sense in a regular application, but daemons which close all file >> descriptors on startup would be handled by the hack. If the hack >> doesn't handle a specific daemon automatically, the daemon could either >> be modified to disable auditing, or its startup scripts could explicitly >> close TTYs to activate the hack. > We do not want a loophole for daemon's to change auditing. We implicitly trust the daemons not to stop auditing completely, anyway. Changing the flag (without using the hack) requires CAP_AUDIT_CONTROL, so the ability to disable auditing can be restricted. >> Is it enough to allow an administrative process to read/modify its >> own "audit TTY input" attribute, or is it necessary to access the attribute >> of other processes? > It should be set by login processes and then be immutable. IOW, it can't be > turned off. In that case, after (/sbin/service sshd restart) executed from an audited session, all SSH future sessions would be audited, including sessions of unprivileged users. Thanks for the comments. Mirek