linux-kernel - Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Oct 2014 17:40:43 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	Richard Guy Briggs <rgb@...hat.com>
Cc:	Eric Paris <eparis@...hat.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org, pmoore@...hat.com
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket

On Tuesday, October 21, 2014 05:08:22 PM Richard Guy Briggs wrote:
> On 14/10/21, Steve Grubb wrote:
> > > super crazy yuck.  audit_log_task_info() ??
> > 
> > audit_log_task_info logs too much information for typical use. There are
> > times when you might want to know everything about what's connecting. But
> > in this case, we don't need anything about groups, saved uids, fsuid, or
> > ppid.
> > 
> > Its a shame we don't have a audit_log_task_info_light function which only
> > records:
> > 
> > pid= auid= uid= subj= comm= exe=  ses= tty=
> 
> We already have audit_log_task() which gives:
> 	auid=
> 	uid=
> 	gid=
> 	ses=
> 	subj=
> 	pid=
> 	comm=
> 	exe=
> This is missing tty=, but has gid=.  Can we please use that function
> instead and add tty=?

gid is important for things that might allow access by file permissions. But 
the syscall logging is going to have that and much more. In this case, access 
is granted by having a posix capability. So, all we want is what's the 
process, who's the user, which session/tty is this coming from to find all 
events that might be related.


> And while we are at it, refactor audit_log_task_info() to call
> audit_log_task()?

That will cause problems at this point.

> Is this standard set above what should be used for certain classes of
> log messages?

Its hard to say if that is sufficient for all cases. When access is granted by 
posix capability, sure. This is probably good for most kernel originating 
events. But there are times extra info is needed.

> Yes, it will be in a different order because we don't have a canonical
> order yet.  Can we accept two orders of keywords so we can start
> canonicalizing, please?

I don't understand what you are getting at.

-Steve

> > > > +     audit_log_format(ab, " group=%d", group);
> > > 
> > > group seems like too easily confused a name.
> > 
> > nlnk-grp is better if its what I think it is.
> 
> Where did you find that name?  That could work and it is shorter, but it
> seems awkwardly optimized.  "nlnk" doesn't appear once in the kernel.
> "nl" is already recognized for netlink, "mcgrp" is already used for
> "multicast group(s)", so I would suggest "nl-mcgrp".
> 
> > -Steve
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs@...hat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems,
> Red Hat Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/