Re: [RFC PATCH] security, capability: pass object information to security_capable
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
On 7/12/19 1:50 PM, James Morris wrote:
On Fri, 12 Jul 2019, Nicholas Franck wrote:
> + case LSM_AUDIT_DATA_CAP: {
> + const struct inode *inode;
> +
> + if (a->u.cap_struct.cad) {
> + switch (a->u.cap_struct.cad->type) {
> + case CAP_AUX_DATA_INODE: {
> + inode = a->u.cap_struct.cad->u.inode;
> +
> + audit_log_format(ab, " dev=");
> + audit_log_untrustedstring(ab,
> + inode->i_sb->s_id);
> + audit_log_format(ab, " ino=%lu",
> + inode->i_ino);
> + break;
> + }
> + }
> + }
> + audit_log_format(ab, " capability=%d ", a->u.cap_struct.cap);
> break;
Will this break any existing userspace log parsers?
I'm hoping not given that we are only adding auxiliary fields and those
are already defined for other AVC audit messages. ausearch appeared to
work fine. Added the linux-audit mailing list to the cc line to get
their view.
Monday, 15 July
Mon, 15 Jul
1:42 p.m.
New subject: [RFC PATCH] security, capability: pass object information to security_capable
On 2019-07-12 14:02, Stephen Smalley wrote:
On 7/12/19 1:50 PM, James Morris wrote:
> On Fri, 12 Jul 2019, Nicholas Franck wrote:
>
This aggressive trimming dropped a bit of helpful context:
+++ b/security/lsm_audit.c
@@ -229,9 +229,26 @@ static void dump_common_audit_data(struct
audit_buffer *ab,
case LSM_AUDIT_DATA_IPC:
audit_log_format(ab, " key=%d ", a->u.ipc_id);
break;
- case LSM_AUDIT_DATA_CAP:
- audit_log_format(ab, " capability=%d ", a->u.cap);
> > + case LSM_AUDIT_DATA_CAP: {
> > + const struct inode *inode;
> > +
> > + if (a->u.cap_struct.cad) {
> > + switch (a->u.cap_struct.cad->type) {
> > + case CAP_AUX_DATA_INODE: {
> > + inode = a->u.cap_struct.cad->u.inode;
> > +
> > + audit_log_format(ab, " dev=");
> > + audit_log_untrustedstring(ab,
> > + inode->i_sb->s_id);
> > + audit_log_format(ab, " ino=%lu",
> > + inode->i_ino);
> > + break;
> > + }
> > + }
> > + }
> > + audit_log_format(ab, " capability=%d ", a->u.cap_struct.cap);
> > break;
+ }
case LSM_AUDIT_DATA_PATH: {
struct inode *inode;
>
> Will this break any existing userspace log parsers?
I'm hoping not given that we are only adding auxiliary fields and those are
already defined for other AVC audit messages. ausearch appeared to work
fine. Added the linux-audit mailing list to the cc line to get their view.
Generally, additional or optional fields should only be added after
existing ones. Also, generally, fields should not be optional, but this
is tricky since it gobbles network and cpu bandwidth and disk space and
there are lots of precedents to contradict this.
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
1986
days inactive
1989
days old
linux-audit@lists.linux-audit.osci.io
1 comments
2 participants
tags (0)
participants (2)
-
Richard Guy Briggs -
Stephen Smalley