From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [Fwd: [PATCH][RFC] SMACK : add logging support V1] Date: Wed, 01 Apr 2009 14:22:18 -0400 Message-ID: <1238610138.14615.7.camel@localhost.localdomain> References: <49B3AB1A.8040201@numericable.fr> <49CDB485.5010809@schaufler-ca.com> <1238422822.16684.74.camel@localhost.localdomain> <49D10FC5.4060504@numericable.fr> <1238441488.18717.54.camel@localhost.localdomain> <49D28EAC.1040604@numericable.fr> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49D28EAC.1040604@numericable.fr> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Etienne Basset Cc: linux-audit@redhat.com, jmorris@namei.org List-Id: linux-audit@redhat.com On Tue, 2009-03-31 at 23:44 +0200, Etienne Basset wrote: > Eric Paris wrote: > > On Mon, 2009-03-30 at 20:30 +0200, Etienne Basset wrote: > >>> I pretty strongly detest %s these days. Using it on the left side of an > >>> = is ok if you are REALLY careful. Using it on the right makes me > >>> cringe. Can smack labels have characters which are not ascii letters > >>> (spaces?) > >>> > >> no, smack basically do the same tests when importing smack label than you do > >> in kernel/audit.c:audit_string_contains_control > >> except smack allows the '"' character > > > > How did you plan to handle a SMACK label with a ' ? Using the audit > > string functions and being given a label with a " is going to give you > > the hex output. (which might someday turn into better encoding, but I'm > > still waiting to see some code to do it better) > > > hum, since smack labels cannot have special characters and are limited to length 24, > maybe we could just do : > subject=FOO object=BAR > but it would imply using a "object=%s subject=%s" > > or using audit_log_untrustedstring and live with the fact that Labels with '"' will be > printed in hex (i dont expect '"' to be frequently used in labels.) Since it can contain a " you may not use %s. Just go with audit_log_untrustedstring and hope people don't use a " > > Can I suggest if you write userspace tools to do anything with these > > audit records that you use libauparse? So if we do make changes, SMACK > > tools keep working (this is the main problem with changing how SELinux > > uses audit, the userspace tools don't use libauparse so we can't make > > changes in just the kernel+library...) > > > i can have a look, but my first need is /var/log/messages being pretty obvious to read The changes to string encoding and we want to do would actually make records more human readable, so if that's your concern we are good. But, if you ever make tools that parse the raw audit.log rather than using libauparse it possible (likely?) they break someday down the line. Don't forget these are going to show up in /var/log/audit/audit.log if you have auditd running. They'll show up in dmesg/syslog if not. Thanks for trying to share code between LSMs! -Eric