* [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Paul Moore, Eric Paris, Steve Grubb, Richard Guy Briggs,
Jan Kara, Amir Goldstein
The Fanotify API can be used for access control by requesting permission
event notification. The user space tooling that uses it may have a
complicated policy that inherently contains additional context for the
decision. If this information were available in the audit trail, policy
writers can close the loop on debugging policy. Also, if this additional
information were available, it would enable the creation of tools that
can suggest changes to the policy similar to how audit2allow can help
refine labeled security.
This patchset defines a new flag (FAN_INFO) and new extensions that
define additional information which are appended after the response
structure returned from user space on a permission event. The appended
information is organized with headers containing a type and size that
can be delegated to interested subsystems. One new information type is
defined for audit rule number.
A newer kernel will work with an older userspace and an older kernel
will behave as expected and reject a newer userspace, leaving it up to
the newer userspace to test appropriately and adapt as necessary.
The audit function was updated to log the additional information in the
AUDIT_FANOTIFY record. The following is an example of the new record
format:
type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F
changelog:
v1:
- first version by Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
v2:
- enhancements suggested by Jan Kara <jack@suse.cz>
- 1/3 change %d to %u in pr_debug
- 2/3 change response from __u32 to __u16
- mod struct fanotify_response and fanotify_perm_event add extra_info_type, extra_info_buf
- extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN, add struct fanotify_response_audit_rule
- extend debug statements
- remove unneeded macros
- [internal] change interface to finish_permission_event() and process_access_response()
- 3/3 update format of extra information
- [internal] change interface to audit_fanotify()
- change ctx_type= to fan_type=
Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
v3:
- 1/3 switch {,__}audit_fanotify() from uint to u32
- 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid unnecessary churn
- add FAN_EXTRA flag to indicate more info and break with old kernel
- change response from u16 to u32 to avoid endian issues
- change extra_info_buf to union
- move low-cost fd check earlier
- change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
- switch to u32 for internal and __u32 for uapi
Link: https://lore.kernel.org/r/cover.1652724390.git.rgb@redhat.com
v4:
- scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid response == 0
- introduce FANOTIFY_RESPONSE_* macros
- uapi: remove union
- keep original struct fanotify_response, add fan_info infra starting with audit reason
- uapi add struct fanotify_response_info_header{type/pad/len} and struct fanotify_response_info_audit_rule{hdr/rule}
- rename fan_ctx= to fan_info=, FAN_EXTRA to FAN_INFO
- change event struct from type/buf to len/buf
- enable multiple info extensions in one message
- hex encode fan_info in __audit_fanotify()
- record type FANOTIFY extended to "type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F"
Link: https://lore.kernel.org/r/cover.1659981772.git.rgb@redhat.com
Richard Guy Briggs (4):
fanotify: Ensure consistent variable type for response
fanotify: define struct members to hold response decision context
fanotify,audit: Allow audit to use the full permission event response
fanotify,audit: deliver fan_info as a hex-encoded string
fs/notify/fanotify/fanotify.c | 13 +++-
fs/notify/fanotify/fanotify.h | 4 +-
fs/notify/fanotify/fanotify_user.c | 106 ++++++++++++++++++++++-------
include/linux/audit.h | 9 +--
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++++++-
kernel/auditsc.c | 45 +++++++++++-
7 files changed, 174 insertions(+), 35 deletions(-)
--
2.27.0
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, Eric Paris
The Fanotify API can be used for access control by requesting permission
event notification. The user space tooling that uses it may have a
complicated policy that inherently contains additional context for the
decision. If this information were available in the audit trail, policy
writers can close the loop on debugging policy. Also, if this additional
information were available, it would enable the creation of tools that
can suggest changes to the policy similar to how audit2allow can help
refine labeled security.
This patchset defines a new flag (FAN_INFO) and new extensions that
define additional information which are appended after the response
structure returned from user space on a permission event. The appended
information is organized with headers containing a type and size that
can be delegated to interested subsystems. One new information type is
defined for audit rule number.
A newer kernel will work with an older userspace and an older kernel
will behave as expected and reject a newer userspace, leaving it up to
the newer userspace to test appropriately and adapt as necessary.
The audit function was updated to log the additional information in the
AUDIT_FANOTIFY record. The following is an example of the new record
format:
type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F
changelog:
v1:
- first version by Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
v2:
- enhancements suggested by Jan Kara <jack@suse.cz>
- 1/3 change %d to %u in pr_debug
- 2/3 change response from __u32 to __u16
- mod struct fanotify_response and fanotify_perm_event add extra_info_type, extra_info_buf
- extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN, add struct fanotify_response_audit_rule
- extend debug statements
- remove unneeded macros
- [internal] change interface to finish_permission_event() and process_access_response()
- 3/3 update format of extra information
- [internal] change interface to audit_fanotify()
- change ctx_type= to fan_type=
Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
v3:
- 1/3 switch {,__}audit_fanotify() from uint to u32
- 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid unnecessary churn
- add FAN_EXTRA flag to indicate more info and break with old kernel
- change response from u16 to u32 to avoid endian issues
- change extra_info_buf to union
- move low-cost fd check earlier
- change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
- switch to u32 for internal and __u32 for uapi
Link: https://lore.kernel.org/r/cover.1652724390.git.rgb@redhat.com
v4:
- scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid response == 0
- introduce FANOTIFY_RESPONSE_* macros
- uapi: remove union
- keep original struct fanotify_response, add fan_info infra starting with audit reason
- uapi add struct fanotify_response_info_header{type/pad/len} and struct fanotify_response_info_audit_rule{hdr/rule}
- rename fan_ctx= to fan_info=, FAN_EXTRA to FAN_INFO
- change event struct from type/buf to len/buf
- enable multiple info extensions in one message
- hex encode fan_info in __audit_fanotify()
- record type FANOTIFY extended to "type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F"
Link: https://lore.kernel.org/r/cover.1659981772.git.rgb@redhat.com
Richard Guy Briggs (4):
fanotify: Ensure consistent variable type for response
fanotify: define struct members to hold response decision context
fanotify,audit: Allow audit to use the full permission event response
fanotify,audit: deliver fan_info as a hex-encoded string
fs/notify/fanotify/fanotify.c | 13 +++-
fs/notify/fanotify/fanotify.h | 4 +-
fs/notify/fanotify/fanotify_user.c | 106 ++++++++++++++++++++++-------
include/linux/audit.h | 9 +--
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++++++-
kernel/auditsc.c | 45 +++++++++++-
7 files changed, 174 insertions(+), 35 deletions(-)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH v4 1/4] fanotify: Ensure consistent variable type for response
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-09 17:22 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Paul Moore, Eric Paris, Steve Grubb, Richard Guy Briggs,
Jan Kara, Amir Goldstein
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 80e0ec95b113..abfa3712c185 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response; /* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index c2255b440df9..ff67ca0d25cc 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(&group->notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group *group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 00f7a80f1a3e..3ea198a2cd59 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -417,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
extern void __audit_mmap_fd(int fd, int flags);
extern void __audit_openat2_how(struct open_how *how);
extern void __audit_log_kern_module(char *name);
-extern void __audit_fanotify(unsigned int response);
+extern void __audit_fanotify(u32 response);
extern void __audit_tk_injoffset(struct timespec64 offset);
extern void __audit_ntp_log(const struct audit_ntp_data *ad);
extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
@@ -524,7 +524,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -684,7 +684,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f3a2abd6d1a1..433418d73584 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2899,7 +2899,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 1/4] fanotify: Ensure consistent variable type for response
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, Eric Paris
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses u32 so that there is
no sign extension or truncation of the user space response.
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 6 +++---
include/linux/audit.h | 6 +++---
kernel/auditsc.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 80e0ec95b113..abfa3712c185 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -425,7 +425,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response; /* userspace answer to the event */
+ u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index c2255b440df9..ff67ca0d25cc 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,7 +289,7 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ u32 response)
__releases(&group->notification_lock)
{
bool destroy = false;
@@ -310,9 +310,9 @@ static int process_access_response(struct fsnotify_group *group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ u32 response = response_struct->response;
- pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
+ pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
fd, response);
/*
* make sure the response is valid, if invalid we do nothing and either
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 00f7a80f1a3e..3ea198a2cd59 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -417,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
extern void __audit_mmap_fd(int fd, int flags);
extern void __audit_openat2_how(struct open_how *how);
extern void __audit_log_kern_module(char *name);
-extern void __audit_fanotify(unsigned int response);
+extern void __audit_fanotify(u32 response);
extern void __audit_tk_injoffset(struct timespec64 offset);
extern void __audit_ntp_log(const struct audit_ntp_data *ad);
extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
@@ -524,7 +524,7 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{
if (!audit_dummy_context())
__audit_fanotify(response);
@@ -684,7 +684,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(unsigned int response)
+static inline void audit_fanotify(u32 response)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f3a2abd6d1a1..433418d73584 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2899,7 +2899,7 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(unsigned int response)
+void __audit_fanotify(u32 response)
{
audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY, "resp=%u", response);
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-09 17:22 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Paul Moore, Eric Paris, Steve Grubb, Richard Guy Briggs,
Jan Kara, Amir Goldstein
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.c | 10 ++-
fs/notify/fanotify/fanotify.h | 2 +
fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++++++-
5 files changed, 123 insertions(+), 25 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 4f897e109547..0f36062521f4 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
case FAN_DENY:
- default:
ret = -EPERM;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
}
/* Check if the response should be audited */
@@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->info_len = 0;
+ pevent->info_buf = NULL;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
@@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
static void fanotify_free_perm_event(struct fanotify_event *event)
{
path_put(fanotify_event_path(event));
+ kfree(FANOTIFY_PERM(event)->info_buf);
kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
}
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index abfa3712c185..14c30e173632 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,8 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ size_t info_len;
+ char *info_buf;
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index ff67ca0d25cc..a4ae953f0e62 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_response *response,
+ size_t info_len, char *info_buf)
__releases(&group->notification_lock)
{
bool destroy = false;
assert_spin_locked(&group->notification_lock);
- event->response = response;
+ event->response = response->response & ~FAN_INFO;
+ if (response->response & FAN_INFO) {
+ event->info_len = info_len;
+ event->info_buf = info_buf;
+ }
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ const char __user *buf,
+ size_t count)
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
u32 response = response_struct->response;
+ struct fanotify_response_info_header info_hdr;
+ char *info_buf = NULL;
- pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
- fd, response);
+ pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
+ group, fd, response, info_buf, count);
/*
* make sure the response is valid, if invalid we do nothing and either
* userspace can send a valid response or we will clean it up after the
* timeout
*/
- switch (response & ~FAN_AUDIT) {
+ if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
+ return -EINVAL;
+ switch (response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
case FAN_DENY:
break;
default:
return -EINVAL;
}
-
- if (fd < 0)
- return -EINVAL;
-
if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
return -EINVAL;
+ if (fd < 0)
+ return -EINVAL;
+ if (response & FAN_INFO) {
+ size_t c = count;
+ const char __user *ib = buf;
+ if (c <= 0)
+ return -EINVAL;
+ while (c >= sizeof(info_hdr)) {
+ if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
+ return -EFAULT;
+ if (info_hdr.pad != 0)
+ return -EINVAL;
+ if (c < info_hdr.len)
+ return -EINVAL;
+ switch (info_hdr.type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ break;
+ case FAN_RESPONSE_INFO_NONE:
+ default:
+ return -EINVAL;
+ }
+ c -= info_hdr.len;
+ ib += info_hdr.len;
+ }
+ if (c != 0)
+ return -EINVAL;
+ /* Simplistic check for now */
+ if (count != sizeof(struct fanotify_response_info_audit_rule))
+ return -EINVAL;
+ info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
+ GFP_KERNEL);
+ if (!info_buf)
+ return -ENOMEM;
+ if (copy_from_user(info_buf, buf, count))
+ return -EFAULT;
+ }
spin_lock(&group->notification_lock);
list_for_each_entry(event, &group->fanotify_data.access_list,
fae.fse.list) {
@@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
continue;
list_del_init(&event->fae.fse.list);
- finish_permission_event(group, event, response);
+ /* finish_permission_event() eats info_buf */
+ finish_permission_event(group, event, response_struct,
+ count, info_buf);
wake_up(&group->fanotify_data.access_waitq);
return 0;
}
@@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
fsnotify_destroy_event(group, &event->fse);
} else {
if (ret <= 0) {
+ struct fanotify_response response = {
+ .fd = FAN_NOFD,
+ .response = FAN_DENY };
+
spin_lock(&group->notification_lock);
finish_permission_event(group,
- FANOTIFY_PERM(event), FAN_DENY);
+ FANOTIFY_PERM(event), &response,
+ 0, NULL);
wake_up(&group->fanotify_data.access_waitq);
} else {
spin_lock(&group->notification_lock);
@@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
{
- struct fanotify_response response = { .fd = -1, .response = -1 };
+ struct fanotify_response response;
struct fsnotify_group *group;
int ret;
+ const char __user *info_buf = buf + sizeof(struct fanotify_response);
+ size_t c;
if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
return -EINVAL;
group = file->private_data;
- if (count < sizeof(response))
- return -EINVAL;
-
- count = sizeof(response);
-
pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
- if (copy_from_user(&response, buf, count))
+ if (count < sizeof(response))
+ return -EINVAL;
+ if (copy_from_user(&response, buf, sizeof(response)))
return -EFAULT;
- ret = process_access_response(group, &response);
+ c = count - sizeof(response);
+ if (response.response & FAN_INFO) {
+ if (c < sizeof(struct fanotify_response_info_header))
+ return -EINVAL;
+ } else {
+ if (c != 0)
+ return -EINVAL;
+ }
+ ret = process_access_response(group, &response, info_buf, c);
if (ret < 0)
count = ret;
@@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
{
struct fsnotify_group *group = file->private_data;
struct fsnotify_event *fsn_event;
+ struct fanotify_response response = {
+ .fd = FAN_NOFD,
+ .response = FAN_ALLOW };
/*
* Stop new events from arriving in the notification queue. since
@@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
event = list_first_entry(&group->fanotify_data.access_list,
struct fanotify_perm_event, fae.fse.list);
list_del_init(&event->fae.fse.list);
- finish_permission_event(group, event, FAN_ALLOW);
+ finish_permission_event(group, event, &response, 0, NULL);
spin_lock(&group->notification_lock);
}
@@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
fsnotify_destroy_event(group, fsn_event);
} else {
finish_permission_event(group, FANOTIFY_PERM(event),
- FAN_ALLOW);
+ &response, 0, NULL);
}
spin_lock(&group->notification_lock);
}
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index edc28555814c..ce9f97eb69f2 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -114,6 +114,11 @@
#define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
FANOTIFY_EVENT_FLAGS)
+/* This mask is to check for invalid bits of a user space permission response */
+#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
+#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
+#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
+
/* Do not use these old uapi constants internally */
#undef FAN_ALL_CLASS_BITS
#undef FAN_ALL_INIT_FLAGS
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index f1f89132d60e..4d08823a5698 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -180,15 +180,40 @@ struct fanotify_event_info_error {
__u32 error_count;
};
+/*
+ * User space may need to record additional information about its decision.
+ * The extra information type records what kind of information is included.
+ * The default is none. We also define an extra information buffer whose
+ * size is determined by the extra information type.
+ *
+ * If the context type is Rule, then the context following is the rule number
+ * that triggered the user space decision.
+ */
+
+#define FAN_RESPONSE_INFO_NONE 0
+#define FAN_RESPONSE_INFO_AUDIT_RULE 1
+
struct fanotify_response {
__s32 fd;
__u32 response;
};
+struct fanotify_response_info_header {
+ __u8 type;
+ __u8 pad;
+ __u16 len;
+};
+
+struct fanotify_response_info_audit_rule {
+ struct fanotify_response_info_header hdr;
+ __u32 audit_rule;
+};
+
/* Legit userspace responses to a _PERM event */
#define FAN_ALLOW 0x01
#define FAN_DENY 0x02
-#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
+#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
+#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
/* No fd set in event */
#define FAN_NOFD -1
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, Eric Paris
This patch adds a flag, FAN_INFO and an extensible buffer to provide
additional information about response decisions. The buffer contains
one or more headers defining the information type and the length of the
following information. The patch defines one additional information
type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
allow for the creation of other information types in the future if other
users of the API identify different needs.
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
Suggested-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.c | 10 ++-
fs/notify/fanotify/fanotify.h | 2 +
fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
include/linux/fanotify.h | 5 ++
include/uapi/linux/fanotify.h | 27 +++++++-
5 files changed, 123 insertions(+), 25 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 4f897e109547..0f36062521f4 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
ret = 0;
break;
case FAN_DENY:
- default:
ret = -EPERM;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
}
/* Check if the response should be audited */
@@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
pevent->response = 0;
+ pevent->info_len = 0;
+ pevent->info_buf = NULL;
pevent->state = FAN_EVENT_INIT;
pevent->path = *path;
path_get(path);
@@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
static void fanotify_free_perm_event(struct fanotify_event *event)
{
path_put(fanotify_event_path(event));
+ kfree(FANOTIFY_PERM(event)->info_buf);
kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
}
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index abfa3712c185..14c30e173632 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -428,6 +428,8 @@ struct fanotify_perm_event {
u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
+ size_t info_len;
+ char *info_buf;
};
static inline struct fanotify_perm_event *
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index ff67ca0d25cc..a4ae953f0e62 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- u32 response)
+ struct fanotify_response *response,
+ size_t info_len, char *info_buf)
__releases(&group->notification_lock)
{
bool destroy = false;
assert_spin_locked(&group->notification_lock);
- event->response = response;
+ event->response = response->response & ~FAN_INFO;
+ if (response->response & FAN_INFO) {
+ event->info_len = info_len;
+ event->info_buf = info_buf;
+ }
if (event->state == FAN_EVENT_CANCELED)
destroy = true;
else
@@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
}
static int process_access_response(struct fsnotify_group *group,
- struct fanotify_response *response_struct)
+ struct fanotify_response *response_struct,
+ const char __user *buf,
+ size_t count)
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
u32 response = response_struct->response;
+ struct fanotify_response_info_header info_hdr;
+ char *info_buf = NULL;
- pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
- fd, response);
+ pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
+ group, fd, response, info_buf, count);
/*
* make sure the response is valid, if invalid we do nothing and either
* userspace can send a valid response or we will clean it up after the
* timeout
*/
- switch (response & ~FAN_AUDIT) {
+ if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
+ return -EINVAL;
+ switch (response & FANOTIFY_RESPONSE_ACCESS) {
case FAN_ALLOW:
case FAN_DENY:
break;
default:
return -EINVAL;
}
-
- if (fd < 0)
- return -EINVAL;
-
if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
return -EINVAL;
+ if (fd < 0)
+ return -EINVAL;
+ if (response & FAN_INFO) {
+ size_t c = count;
+ const char __user *ib = buf;
+ if (c <= 0)
+ return -EINVAL;
+ while (c >= sizeof(info_hdr)) {
+ if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
+ return -EFAULT;
+ if (info_hdr.pad != 0)
+ return -EINVAL;
+ if (c < info_hdr.len)
+ return -EINVAL;
+ switch (info_hdr.type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ break;
+ case FAN_RESPONSE_INFO_NONE:
+ default:
+ return -EINVAL;
+ }
+ c -= info_hdr.len;
+ ib += info_hdr.len;
+ }
+ if (c != 0)
+ return -EINVAL;
+ /* Simplistic check for now */
+ if (count != sizeof(struct fanotify_response_info_audit_rule))
+ return -EINVAL;
+ info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
+ GFP_KERNEL);
+ if (!info_buf)
+ return -ENOMEM;
+ if (copy_from_user(info_buf, buf, count))
+ return -EFAULT;
+ }
spin_lock(&group->notification_lock);
list_for_each_entry(event, &group->fanotify_data.access_list,
fae.fse.list) {
@@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
continue;
list_del_init(&event->fae.fse.list);
- finish_permission_event(group, event, response);
+ /* finish_permission_event() eats info_buf */
+ finish_permission_event(group, event, response_struct,
+ count, info_buf);
wake_up(&group->fanotify_data.access_waitq);
return 0;
}
@@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
fsnotify_destroy_event(group, &event->fse);
} else {
if (ret <= 0) {
+ struct fanotify_response response = {
+ .fd = FAN_NOFD,
+ .response = FAN_DENY };
+
spin_lock(&group->notification_lock);
finish_permission_event(group,
- FANOTIFY_PERM(event), FAN_DENY);
+ FANOTIFY_PERM(event), &response,
+ 0, NULL);
wake_up(&group->fanotify_data.access_waitq);
} else {
spin_lock(&group->notification_lock);
@@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
{
- struct fanotify_response response = { .fd = -1, .response = -1 };
+ struct fanotify_response response;
struct fsnotify_group *group;
int ret;
+ const char __user *info_buf = buf + sizeof(struct fanotify_response);
+ size_t c;
if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
return -EINVAL;
group = file->private_data;
- if (count < sizeof(response))
- return -EINVAL;
-
- count = sizeof(response);
-
pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
- if (copy_from_user(&response, buf, count))
+ if (count < sizeof(response))
+ return -EINVAL;
+ if (copy_from_user(&response, buf, sizeof(response)))
return -EFAULT;
- ret = process_access_response(group, &response);
+ c = count - sizeof(response);
+ if (response.response & FAN_INFO) {
+ if (c < sizeof(struct fanotify_response_info_header))
+ return -EINVAL;
+ } else {
+ if (c != 0)
+ return -EINVAL;
+ }
+ ret = process_access_response(group, &response, info_buf, c);
if (ret < 0)
count = ret;
@@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
{
struct fsnotify_group *group = file->private_data;
struct fsnotify_event *fsn_event;
+ struct fanotify_response response = {
+ .fd = FAN_NOFD,
+ .response = FAN_ALLOW };
/*
* Stop new events from arriving in the notification queue. since
@@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
event = list_first_entry(&group->fanotify_data.access_list,
struct fanotify_perm_event, fae.fse.list);
list_del_init(&event->fae.fse.list);
- finish_permission_event(group, event, FAN_ALLOW);
+ finish_permission_event(group, event, &response, 0, NULL);
spin_lock(&group->notification_lock);
}
@@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
fsnotify_destroy_event(group, fsn_event);
} else {
finish_permission_event(group, FANOTIFY_PERM(event),
- FAN_ALLOW);
+ &response, 0, NULL);
}
spin_lock(&group->notification_lock);
}
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index edc28555814c..ce9f97eb69f2 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -114,6 +114,11 @@
#define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
FANOTIFY_EVENT_FLAGS)
+/* This mask is to check for invalid bits of a user space permission response */
+#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
+#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
+#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
+
/* Do not use these old uapi constants internally */
#undef FAN_ALL_CLASS_BITS
#undef FAN_ALL_INIT_FLAGS
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index f1f89132d60e..4d08823a5698 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -180,15 +180,40 @@ struct fanotify_event_info_error {
__u32 error_count;
};
+/*
+ * User space may need to record additional information about its decision.
+ * The extra information type records what kind of information is included.
+ * The default is none. We also define an extra information buffer whose
+ * size is determined by the extra information type.
+ *
+ * If the context type is Rule, then the context following is the rule number
+ * that triggered the user space decision.
+ */
+
+#define FAN_RESPONSE_INFO_NONE 0
+#define FAN_RESPONSE_INFO_AUDIT_RULE 1
+
struct fanotify_response {
__s32 fd;
__u32 response;
};
+struct fanotify_response_info_header {
+ __u8 type;
+ __u8 pad;
+ __u16 len;
+};
+
+struct fanotify_response_info_audit_rule {
+ struct fanotify_response_info_header hdr;
+ __u32 audit_rule;
+};
+
/* Legit userspace responses to a _PERM event */
#define FAN_ALLOW 0x01
#define FAN_DENY 0x02
-#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
+#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
+#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
/* No fd set in event */
#define FAN_NOFD -1
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-09 17:22 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Paul Moore, Eric Paris, Steve Grubb, Richard Guy Briggs,
Jan Kara, Amir Goldstein
This patch passes the full value so that the audit function can use all
of it. The audit function was updated to log the additional information in
the AUDIT_FANOTIFY record. The following is an example of the new record
format:
type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.c | 3 ++-
include/linux/audit.h | 9 +++++----
kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 0f36062521f4..36c3ed1af085 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -276,7 +276,8 @@ static int fanotify_get_response(struct fsnotify_group *group,
/* Check if the response should be audited */
if (event->response & FAN_AUDIT)
- audit_fanotify(event->response & ~FAN_AUDIT);
+ audit_fanotify(event->response & ~FAN_AUDIT,
+ event->info_len, event->info_buf);
pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
group, event, ret);
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3ea198a2cd59..c69efdba12ca 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -14,6 +14,7 @@
#include <linux/audit_arch.h>
#include <uapi/linux/audit.h>
#include <uapi/linux/netfilter/nf_tables.h>
+#include <uapi/linux/fanotify.h>
#define AUDIT_INO_UNSET ((unsigned long)-1)
#define AUDIT_DEV_UNSET ((dev_t)-1)
@@ -417,7 +418,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
extern void __audit_mmap_fd(int fd, int flags);
extern void __audit_openat2_how(struct open_how *how);
extern void __audit_log_kern_module(char *name);
-extern void __audit_fanotify(u32 response);
+extern void __audit_fanotify(u32 response, size_t len, char *buf);
extern void __audit_tk_injoffset(struct timespec64 offset);
extern void __audit_ntp_log(const struct audit_ntp_data *ad);
extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
@@ -524,10 +525,10 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, size_t len, char *buf)
{
if (!audit_dummy_context())
- __audit_fanotify(response);
+ __audit_fanotify(response, len, buf);
}
static inline void audit_tk_injoffset(struct timespec64 offset)
@@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, size_t len, char *buf)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 433418d73584..f000fec52360 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -64,6 +64,7 @@
#include <uapi/linux/limits.h>
#include <uapi/linux/netfilter/nf_tables.h>
#include <uapi/linux/openat2.h> // struct open_how
+#include <uapi/linux/fanotify.h>
#include "audit.h"
@@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(u32 response)
+void __audit_fanotify(u32 response, size_t len, char *buf)
{
- audit_log(audit_context(), GFP_KERNEL,
- AUDIT_FANOTIFY, "resp=%u", response);
+ struct fanotify_response_info_audit_rule *friar;
+ size_t c = len;
+ char *ib = buf;
+
+ if (!(len && buf)) {
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=0 fan_info=?", response);
+ return;
+ }
+ while (c >= sizeof(struct fanotify_response_info_header)) {
+ friar = (struct fanotify_response_info_audit_rule *)buf;
+ switch (friar->hdr.type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ if (friar->hdr.len < sizeof(*friar)) {
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=(incomplete)",
+ response, friar->hdr.type);
+ return;
+ }
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=%u",
+ response, friar->hdr.type, friar->audit_rule);
+ }
+ c -= friar->hdr.len;
+ ib += friar->hdr.len;
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, Eric Paris
This patch passes the full value so that the audit function can use all
of it. The audit function was updated to log the additional information in
the AUDIT_FANOTIFY record. The following is an example of the new record
format:
type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
Suggested-by: Steve Grubb <sgrubb@redhat.com>
Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
fs/notify/fanotify/fanotify.c | 3 ++-
include/linux/audit.h | 9 +++++----
kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 0f36062521f4..36c3ed1af085 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -276,7 +276,8 @@ static int fanotify_get_response(struct fsnotify_group *group,
/* Check if the response should be audited */
if (event->response & FAN_AUDIT)
- audit_fanotify(event->response & ~FAN_AUDIT);
+ audit_fanotify(event->response & ~FAN_AUDIT,
+ event->info_len, event->info_buf);
pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
group, event, ret);
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3ea198a2cd59..c69efdba12ca 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -14,6 +14,7 @@
#include <linux/audit_arch.h>
#include <uapi/linux/audit.h>
#include <uapi/linux/netfilter/nf_tables.h>
+#include <uapi/linux/fanotify.h>
#define AUDIT_INO_UNSET ((unsigned long)-1)
#define AUDIT_DEV_UNSET ((dev_t)-1)
@@ -417,7 +418,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
extern void __audit_mmap_fd(int fd, int flags);
extern void __audit_openat2_how(struct open_how *how);
extern void __audit_log_kern_module(char *name);
-extern void __audit_fanotify(u32 response);
+extern void __audit_fanotify(u32 response, size_t len, char *buf);
extern void __audit_tk_injoffset(struct timespec64 offset);
extern void __audit_ntp_log(const struct audit_ntp_data *ad);
extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
@@ -524,10 +525,10 @@ static inline void audit_log_kern_module(char *name)
__audit_log_kern_module(name);
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, size_t len, char *buf)
{
if (!audit_dummy_context())
- __audit_fanotify(response);
+ __audit_fanotify(response, len, buf);
}
static inline void audit_tk_injoffset(struct timespec64 offset)
@@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name)
{
}
-static inline void audit_fanotify(u32 response)
+static inline void audit_fanotify(u32 response, size_t len, char *buf)
{ }
static inline void audit_tk_injoffset(struct timespec64 offset)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 433418d73584..f000fec52360 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -64,6 +64,7 @@
#include <uapi/linux/limits.h>
#include <uapi/linux/netfilter/nf_tables.h>
#include <uapi/linux/openat2.h> // struct open_how
+#include <uapi/linux/fanotify.h>
#include "audit.h"
@@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
context->type = AUDIT_KERN_MODULE;
}
-void __audit_fanotify(u32 response)
+void __audit_fanotify(u32 response, size_t len, char *buf)
{
- audit_log(audit_context(), GFP_KERNEL,
- AUDIT_FANOTIFY, "resp=%u", response);
+ struct fanotify_response_info_audit_rule *friar;
+ size_t c = len;
+ char *ib = buf;
+
+ if (!(len && buf)) {
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=0 fan_info=?", response);
+ return;
+ }
+ while (c >= sizeof(struct fanotify_response_info_header)) {
+ friar = (struct fanotify_response_info_audit_rule *)buf;
+ switch (friar->hdr.type) {
+ case FAN_RESPONSE_INFO_AUDIT_RULE:
+ if (friar->hdr.len < sizeof(*friar)) {
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=(incomplete)",
+ response, friar->hdr.type);
+ return;
+ }
+ audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
+ "resp=%u fan_type=%u fan_info=%u",
+ response, friar->hdr.type, friar->audit_rule);
+ }
+ c -= friar->hdr.len;
+ ib += friar->hdr.len;
+ }
}
void __audit_tk_injoffset(struct timespec64 offset)
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-09 17:22 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Paul Moore, Eric Paris, Steve Grubb, Richard Guy Briggs,
Jan Kara, Amir Goldstein
Currently the only type of fanotify info that is defined is an audit
rule number, but convert it to hex encoding to future-proof the field.
Sample record:
type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F
Suggested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditsc.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f000fec52360..0f747015c577 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf)
if (!(len && buf)) {
audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=0 fan_info=?", response);
+ "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
return;
}
while (c >= sizeof(struct fanotify_response_info_header)) {
+ struct audit_context *ctx = audit_context();
+ struct audit_buffer *ab;
+
friar = (struct fanotify_response_info_audit_rule *)buf;
switch (friar->hdr.type) {
case FAN_RESPONSE_INFO_AUDIT_RULE:
if (friar->hdr.len < sizeof(*friar)) {
- audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=%u fan_info=(incomplete)",
- response, friar->hdr.type);
+ ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
+ if (ab) {
+ audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
+ response, friar->hdr.type);
+#define INCOMPLETE "(incomplete)"
+ audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
+ audit_log_end(ab);
+ }
return;
}
- audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=%u fan_info=%u",
- response, friar->hdr.type, friar->audit_rule);
+ ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
+ if (ab) {
+ audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
+ response, friar->hdr.type);
+ audit_log_n_hex(ab, (char *)&friar->audit_rule,
+ sizeof(friar->audit_rule));
+ audit_log_end(ab);
+
+ }
}
c -= friar->hdr.len;
ib += friar->hdr.len;
--
2.27.0
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
@ 2022-08-09 17:22 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-09 17:22 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, Eric Paris
Currently the only type of fanotify info that is defined is an audit
rule number, but convert it to hex encoding to future-proof the field.
Sample record:
type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F
Suggested-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
kernel/auditsc.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f000fec52360..0f747015c577 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf)
if (!(len && buf)) {
audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=0 fan_info=?", response);
+ "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
return;
}
while (c >= sizeof(struct fanotify_response_info_header)) {
+ struct audit_context *ctx = audit_context();
+ struct audit_buffer *ab;
+
friar = (struct fanotify_response_info_audit_rule *)buf;
switch (friar->hdr.type) {
case FAN_RESPONSE_INFO_AUDIT_RULE:
if (friar->hdr.len < sizeof(*friar)) {
- audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=%u fan_info=(incomplete)",
- response, friar->hdr.type);
+ ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
+ if (ab) {
+ audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
+ response, friar->hdr.type);
+#define INCOMPLETE "(incomplete)"
+ audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
+ audit_log_end(ab);
+ }
return;
}
- audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
- "resp=%u fan_type=%u fan_info=%u",
- response, friar->hdr.type, friar->audit_rule);
+ ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
+ if (ab) {
+ audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
+ response, friar->hdr.type);
+ audit_log_n_hex(ab, (char *)&friar->audit_rule,
+ sizeof(friar->audit_rule));
+ audit_log_end(ab);
+
+ }
}
c -= friar->hdr.len;
ib += friar->hdr.len;
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-10 5:21 ` Amir Goldstein
-1 siblings, 0 replies; 91+ messages in thread
From: Amir Goldstein @ 2022-08-10 5:21 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Steve Grubb, Jan Kara, Linux API
[+linux-api]
On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> The Fanotify API can be used for access control by requesting permission
> event notification. The user space tooling that uses it may have a
> complicated policy that inherently contains additional context for the
> decision. If this information were available in the audit trail, policy
> writers can close the loop on debugging policy. Also, if this additional
> information were available, it would enable the creation of tools that
> can suggest changes to the policy similar to how audit2allow can help
> refine labeled security.
>
> This patchset defines a new flag (FAN_INFO) and new extensions that
> define additional information which are appended after the response
> structure returned from user space on a permission event. The appended
> information is organized with headers containing a type and size that
> can be delegated to interested subsystems. One new information type is
> defined for audit rule number.
>
> A newer kernel will work with an older userspace and an older kernel
> will behave as expected and reject a newer userspace, leaving it up to
> the newer userspace to test appropriately and adapt as necessary.
Since you did not accept my suggestion of FAN_TEST response code [1],
I am not really sure how you envision that "adapt as necessary" part.
A well designed UAPI should allow newer userspace to check for kernel
support of FAN_INFO on initialization.
For example, without this property of UAPI, it is going to be hard to write an
LTP test for the new functionality that does not run on older kernels.
As far as I can tell, your proposed UAPI does not provide this functionality.
It allows newer userspace to check for support of FAN_INFO only as a
response to a permission event.
You never replied to my question to explain why you think FAN_TEST
complicated things. The only purpose of FAN_TEST is for userspace
to be able to test FAN_INFO kernel support without providing a valid fd.
[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
>
> The audit function was updated to log the additional information in the
> AUDIT_FANOTIFY record. The following is an example of the new record
> format:
>
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F
>
> changelog:
> v1:
> - first version by Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
>
> v2:
> - enhancements suggested by Jan Kara <jack@suse.cz>
> - 1/3 change %d to %u in pr_debug
> - 2/3 change response from __u32 to __u16
> - mod struct fanotify_response and fanotify_perm_event add extra_info_type, extra_info_buf
> - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN, add struct fanotify_response_audit_rule
> - extend debug statements
> - remove unneeded macros
> - [internal] change interface to finish_permission_event() and process_access_response()
> - 3/3 update format of extra information
> - [internal] change interface to audit_fanotify()
> - change ctx_type= to fan_type=
> Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
>
> v3:
> - 1/3 switch {,__}audit_fanotify() from uint to u32
> - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid unnecessary churn
> - add FAN_EXTRA flag to indicate more info and break with old kernel
> - change response from u16 to u32 to avoid endian issues
> - change extra_info_buf to union
> - move low-cost fd check earlier
> - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
> - switch to u32 for internal and __u32 for uapi
> Link: https://lore.kernel.org/r/cover.1652724390.git.rgb@redhat.com
Link seems broken?
>
> v4:
> - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid response == 0
> - introduce FANOTIFY_RESPONSE_* macros
> - uapi: remove union
> - keep original struct fanotify_response, add fan_info infra starting with audit reason
> - uapi add struct fanotify_response_info_header{type/pad/len} and struct fanotify_response_info_audit_rule{hdr/rule}
> - rename fan_ctx= to fan_info=, FAN_EXTRA to FAN_INFO
> - change event struct from type/buf to len/buf
> - enable multiple info extensions in one message
> - hex encode fan_info in __audit_fanotify()
> - record type FANOTIFY extended to "type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F"
> Link: https://lore.kernel.org/r/cover.1659981772.git.rgb@redhat.com
Link seems broken?
Thanks,
Amir.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info
@ 2022-08-10 5:21 ` Amir Goldstein
0 siblings, 0 replies; 91+ messages in thread
From: Amir Goldstein @ 2022-08-10 5:21 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Linux API, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
[+linux-api]
On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> The Fanotify API can be used for access control by requesting permission
> event notification. The user space tooling that uses it may have a
> complicated policy that inherently contains additional context for the
> decision. If this information were available in the audit trail, policy
> writers can close the loop on debugging policy. Also, if this additional
> information were available, it would enable the creation of tools that
> can suggest changes to the policy similar to how audit2allow can help
> refine labeled security.
>
> This patchset defines a new flag (FAN_INFO) and new extensions that
> define additional information which are appended after the response
> structure returned from user space on a permission event. The appended
> information is organized with headers containing a type and size that
> can be delegated to interested subsystems. One new information type is
> defined for audit rule number.
>
> A newer kernel will work with an older userspace and an older kernel
> will behave as expected and reject a newer userspace, leaving it up to
> the newer userspace to test appropriately and adapt as necessary.
Since you did not accept my suggestion of FAN_TEST response code [1],
I am not really sure how you envision that "adapt as necessary" part.
A well designed UAPI should allow newer userspace to check for kernel
support of FAN_INFO on initialization.
For example, without this property of UAPI, it is going to be hard to write an
LTP test for the new functionality that does not run on older kernels.
As far as I can tell, your proposed UAPI does not provide this functionality.
It allows newer userspace to check for support of FAN_INFO only as a
response to a permission event.
You never replied to my question to explain why you think FAN_TEST
complicated things. The only purpose of FAN_TEST is for userspace
to be able to test FAN_INFO kernel support without providing a valid fd.
[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
>
> The audit function was updated to log the additional information in the
> AUDIT_FANOTIFY record. The following is an example of the new record
> format:
>
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F
>
> changelog:
> v1:
> - first version by Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
>
> v2:
> - enhancements suggested by Jan Kara <jack@suse.cz>
> - 1/3 change %d to %u in pr_debug
> - 2/3 change response from __u32 to __u16
> - mod struct fanotify_response and fanotify_perm_event add extra_info_type, extra_info_buf
> - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN, add struct fanotify_response_audit_rule
> - extend debug statements
> - remove unneeded macros
> - [internal] change interface to finish_permission_event() and process_access_response()
> - 3/3 update format of extra information
> - [internal] change interface to audit_fanotify()
> - change ctx_type= to fan_type=
> Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
>
> v3:
> - 1/3 switch {,__}audit_fanotify() from uint to u32
> - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid unnecessary churn
> - add FAN_EXTRA flag to indicate more info and break with old kernel
> - change response from u16 to u32 to avoid endian issues
> - change extra_info_buf to union
> - move low-cost fd check earlier
> - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
> - switch to u32 for internal and __u32 for uapi
> Link: https://lore.kernel.org/r/cover.1652724390.git.rgb@redhat.com
Link seems broken?
>
> v4:
> - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid response == 0
> - introduce FANOTIFY_RESPONSE_* macros
> - uapi: remove union
> - keep original struct fanotify_response, add fan_info infra starting with audit reason
> - uapi add struct fanotify_response_info_header{type/pad/len} and struct fanotify_response_info_audit_rule{hdr/rule}
> - rename fan_ctx= to fan_info=, FAN_EXTRA to FAN_INFO
> - change event struct from type/buf to len/buf
> - enable multiple info extensions in one message
> - hex encode fan_info in __audit_fanotify()
> - record type FANOTIFY extended to "type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F"
> Link: https://lore.kernel.org/r/cover.1659981772.git.rgb@redhat.com
Link seems broken?
Thanks,
Amir.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-10 6:22 ` Amir Goldstein
-1 siblings, 0 replies; 91+ messages in thread
From: Amir Goldstein @ 2022-08-10 6:22 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Steve Grubb, Jan Kara, Linux API
[+linux-api]
On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
Looks mostly fine.
A few small bugs and style suggestions
and one UAPI improvement suggestion.
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 4f897e109547..0f36062521f4 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
> }
>
> /* userspace responded, convert to something usable */
> - switch (event->response & ~FAN_AUDIT) {
> + switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> ret = 0;
> break;
> case FAN_DENY:
> - default:
> ret = -EPERM;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
This is very odd.
Why has this changed?
The return value here is going to the process that
is trying to access the file.
> }
>
> /* Check if the response should be audited */
> @@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
>
> pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
> pevent->response = 0;
> + pevent->info_len = 0;
> + pevent->info_buf = NULL;
> pevent->state = FAN_EVENT_INIT;
> pevent->path = *path;
> path_get(path);
> @@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
> static void fanotify_free_perm_event(struct fanotify_event *event)
> {
> path_put(fanotify_event_path(event));
> + kfree(FANOTIFY_PERM(event)->info_buf);
> kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
> }
>
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
>
> static inline struct fanotify_perm_event *
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
> @@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
> }
>
> static int process_access_response(struct fsnotify_group *group,
> - struct fanotify_response *response_struct)
> + struct fanotify_response *response_struct,
> + const char __user *buf,
> + size_t count)
> {
> struct fanotify_perm_event *event;
> int fd = response_struct->fd;
> u32 response = response_struct->response;
> + struct fanotify_response_info_header info_hdr;
> + char *info_buf = NULL;
>
> - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> - fd, response);
> + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> + group, fd, response, info_buf, count);
> /*
> * make sure the response is valid, if invalid we do nothing and either
> * userspace can send a valid response or we will clean it up after the
> * timeout
> */
> - switch (response & ~FAN_AUDIT) {
> + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> + return -EINVAL;
> + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> case FAN_DENY:
> break;
> default:
> return -EINVAL;
> }
> -
> - if (fd < 0)
> - return -EINVAL;
> -
> if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> return -EINVAL;
> + if (fd < 0)
> + return -EINVAL;
Since you did not accept my suggestion of FAN_TEST [1],
I am not sure why this check was moved.
However, if you move this check past FAN_INFO processing,
you could change the error value to -ENOENT, same as the return value
for an fd that is >= 0 but does not correspond to any pending
permission event.
The idea was that userspace could write a test
fanotify_response_info_audit_rule payload to fanotify fd with FAN_NOFD
in the response.fd field.
On old kernel, this will return EINVAL.
On new kernel, if the fanotify_response_info_audit_rule payload
passes all the validations, this will do nothing and return ENOENT.
[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
> + if (response & FAN_INFO) {
Please split this out to helper process_response_info() and
optionally also helper process_response_info_audit_rule()
> + size_t c = count;
> + const char __user *ib = buf;
>
> + if (c <= 0)
> + return -EINVAL;
This was already checked by the caller.
If you think we need this defence use if (WARN_ON_ONCE())
> + while (c >= sizeof(info_hdr)) {
This while() is a bit confusing.
It suggests that the parser may process multiple info records,
but the code below uses 'count' and assumed single audit rule
record.
Maybe just change this to:
if (WARN_ON_ONCE(c < sizeof(info_hdr))
return -EINVAL
Until the code can really handle multiple records.
> + if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> + return -EFAULT;
> + if (info_hdr.pad != 0)
> + return -EINVAL;
> + if (c < info_hdr.len)
> + return -EINVAL;
> + switch (info_hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + break;
> + case FAN_RESPONSE_INFO_NONE:
> + default:
> + return -EINVAL;
> + }
> + c -= info_hdr.len;
> + ib += info_hdr.len;
> + }
> + if (c != 0)
> + return -EINVAL;
> + /* Simplistic check for now */
> + if (count != sizeof(struct fanotify_response_info_audit_rule))
> + return -EINVAL;
> + info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> + GFP_KERNEL);
> + if (!info_buf)
> + return -ENOMEM;
> + if (copy_from_user(info_buf, buf, count))
> + return -EFAULT;
info_buf allocation is leaked here and also in case 'fd' is not found.
> + }
> spin_lock(&group->notification_lock);
> list_for_each_entry(event, &group->fanotify_data.access_list,
> fae.fse.list) {
> @@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
> continue;
>
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, response);
> + /* finish_permission_event() eats info_buf */
> + finish_permission_event(group, event, response_struct,
> + count, info_buf);
> wake_up(&group->fanotify_data.access_waitq);
> return 0;
> }
> @@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> fsnotify_destroy_event(group, &event->fse);
> } else {
> if (ret <= 0) {
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_DENY };
> +
> spin_lock(&group->notification_lock);
> finish_permission_event(group,
> - FANOTIFY_PERM(event), FAN_DENY);
> + FANOTIFY_PERM(event), &response,
> + 0, NULL);
> wake_up(&group->fanotify_data.access_waitq);
> } else {
> spin_lock(&group->notification_lock);
> @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
>
> static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> {
> - struct fanotify_response response = { .fd = -1, .response = -1 };
> + struct fanotify_response response;
> struct fsnotify_group *group;
> int ret;
> + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> + size_t c;
>
> if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> return -EINVAL;
>
> group = file->private_data;
>
> - if (count < sizeof(response))
> - return -EINVAL;
> -
> - count = sizeof(response);
> -
> pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
>
> - if (copy_from_user(&response, buf, count))
> + if (count < sizeof(response))
> + return -EINVAL;
> + if (copy_from_user(&response, buf, sizeof(response)))
> return -EFAULT;
>
> - ret = process_access_response(group, &response);
> + c = count - sizeof(response);
> + if (response.response & FAN_INFO) {
> + if (c < sizeof(struct fanotify_response_info_header))
> + return -EINVAL;
Should FAN_INFO require FAN_AUDIT?
> + } else {
> + if (c != 0)
> + return -EINVAL;
> + }
> + ret = process_access_response(group, &response, info_buf, c);
> if (ret < 0)
> count = ret;
>
> @@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> {
> struct fsnotify_group *group = file->private_data;
> struct fsnotify_event *fsn_event;
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_ALLOW };
>
> /*
> * Stop new events from arriving in the notification queue. since
> @@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> event = list_first_entry(&group->fanotify_data.access_list,
> struct fanotify_perm_event, fae.fse.list);
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, FAN_ALLOW);
> + finish_permission_event(group, event, &response, 0, NULL);
> spin_lock(&group->notification_lock);
> }
>
> @@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> fsnotify_destroy_event(group, fsn_event);
> } else {
> finish_permission_event(group, FANOTIFY_PERM(event),
> - FAN_ALLOW);
> + &response, 0, NULL);
> }
> spin_lock(&group->notification_lock);
> }
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index edc28555814c..ce9f97eb69f2 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -114,6 +114,11 @@
> #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
> FANOTIFY_EVENT_FLAGS)
>
> +/* This mask is to check for invalid bits of a user space permission response */
> +#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
> +#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
> +#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
> +
> /* Do not use these old uapi constants internally */
> #undef FAN_ALL_CLASS_BITS
> #undef FAN_ALL_INIT_FLAGS
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
> + */
> +
> +#define FAN_RESPONSE_INFO_NONE 0
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
> /* Legit userspace responses to a _PERM event */
> #define FAN_ALLOW 0x01
> #define FAN_DENY 0x02
> -#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
> +#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
> +#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
>
> /* No fd set in event */
> #define FAN_NOFD -1
> --
> 2.27.0
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-10 6:22 ` Amir Goldstein
0 siblings, 0 replies; 91+ messages in thread
From: Amir Goldstein @ 2022-08-10 6:22 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Linux API, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
[+linux-api]
On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
Looks mostly fine.
A few small bugs and style suggestions
and one UAPI improvement suggestion.
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 4f897e109547..0f36062521f4 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
> }
>
> /* userspace responded, convert to something usable */
> - switch (event->response & ~FAN_AUDIT) {
> + switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> ret = 0;
> break;
> case FAN_DENY:
> - default:
> ret = -EPERM;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
This is very odd.
Why has this changed?
The return value here is going to the process that
is trying to access the file.
> }
>
> /* Check if the response should be audited */
> @@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
>
> pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
> pevent->response = 0;
> + pevent->info_len = 0;
> + pevent->info_buf = NULL;
> pevent->state = FAN_EVENT_INIT;
> pevent->path = *path;
> path_get(path);
> @@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
> static void fanotify_free_perm_event(struct fanotify_event *event)
> {
> path_put(fanotify_event_path(event));
> + kfree(FANOTIFY_PERM(event)->info_buf);
> kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
> }
>
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
>
> static inline struct fanotify_perm_event *
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
> @@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
> }
>
> static int process_access_response(struct fsnotify_group *group,
> - struct fanotify_response *response_struct)
> + struct fanotify_response *response_struct,
> + const char __user *buf,
> + size_t count)
> {
> struct fanotify_perm_event *event;
> int fd = response_struct->fd;
> u32 response = response_struct->response;
> + struct fanotify_response_info_header info_hdr;
> + char *info_buf = NULL;
>
> - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> - fd, response);
> + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> + group, fd, response, info_buf, count);
> /*
> * make sure the response is valid, if invalid we do nothing and either
> * userspace can send a valid response or we will clean it up after the
> * timeout
> */
> - switch (response & ~FAN_AUDIT) {
> + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> + return -EINVAL;
> + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> case FAN_DENY:
> break;
> default:
> return -EINVAL;
> }
> -
> - if (fd < 0)
> - return -EINVAL;
> -
> if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> return -EINVAL;
> + if (fd < 0)
> + return -EINVAL;
Since you did not accept my suggestion of FAN_TEST [1],
I am not sure why this check was moved.
However, if you move this check past FAN_INFO processing,
you could change the error value to -ENOENT, same as the return value
for an fd that is >= 0 but does not correspond to any pending
permission event.
The idea was that userspace could write a test
fanotify_response_info_audit_rule payload to fanotify fd with FAN_NOFD
in the response.fd field.
On old kernel, this will return EINVAL.
On new kernel, if the fanotify_response_info_audit_rule payload
passes all the validations, this will do nothing and return ENOENT.
[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
> + if (response & FAN_INFO) {
Please split this out to helper process_response_info() and
optionally also helper process_response_info_audit_rule()
> + size_t c = count;
> + const char __user *ib = buf;
>
> + if (c <= 0)
> + return -EINVAL;
This was already checked by the caller.
If you think we need this defence use if (WARN_ON_ONCE())
> + while (c >= sizeof(info_hdr)) {
This while() is a bit confusing.
It suggests that the parser may process multiple info records,
but the code below uses 'count' and assumed single audit rule
record.
Maybe just change this to:
if (WARN_ON_ONCE(c < sizeof(info_hdr))
return -EINVAL
Until the code can really handle multiple records.
> + if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> + return -EFAULT;
> + if (info_hdr.pad != 0)
> + return -EINVAL;
> + if (c < info_hdr.len)
> + return -EINVAL;
> + switch (info_hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + break;
> + case FAN_RESPONSE_INFO_NONE:
> + default:
> + return -EINVAL;
> + }
> + c -= info_hdr.len;
> + ib += info_hdr.len;
> + }
> + if (c != 0)
> + return -EINVAL;
> + /* Simplistic check for now */
> + if (count != sizeof(struct fanotify_response_info_audit_rule))
> + return -EINVAL;
> + info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> + GFP_KERNEL);
> + if (!info_buf)
> + return -ENOMEM;
> + if (copy_from_user(info_buf, buf, count))
> + return -EFAULT;
info_buf allocation is leaked here and also in case 'fd' is not found.
> + }
> spin_lock(&group->notification_lock);
> list_for_each_entry(event, &group->fanotify_data.access_list,
> fae.fse.list) {
> @@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
> continue;
>
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, response);
> + /* finish_permission_event() eats info_buf */
> + finish_permission_event(group, event, response_struct,
> + count, info_buf);
> wake_up(&group->fanotify_data.access_waitq);
> return 0;
> }
> @@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> fsnotify_destroy_event(group, &event->fse);
> } else {
> if (ret <= 0) {
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_DENY };
> +
> spin_lock(&group->notification_lock);
> finish_permission_event(group,
> - FANOTIFY_PERM(event), FAN_DENY);
> + FANOTIFY_PERM(event), &response,
> + 0, NULL);
> wake_up(&group->fanotify_data.access_waitq);
> } else {
> spin_lock(&group->notification_lock);
> @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
>
> static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> {
> - struct fanotify_response response = { .fd = -1, .response = -1 };
> + struct fanotify_response response;
> struct fsnotify_group *group;
> int ret;
> + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> + size_t c;
>
> if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> return -EINVAL;
>
> group = file->private_data;
>
> - if (count < sizeof(response))
> - return -EINVAL;
> -
> - count = sizeof(response);
> -
> pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
>
> - if (copy_from_user(&response, buf, count))
> + if (count < sizeof(response))
> + return -EINVAL;
> + if (copy_from_user(&response, buf, sizeof(response)))
> return -EFAULT;
>
> - ret = process_access_response(group, &response);
> + c = count - sizeof(response);
> + if (response.response & FAN_INFO) {
> + if (c < sizeof(struct fanotify_response_info_header))
> + return -EINVAL;
Should FAN_INFO require FAN_AUDIT?
> + } else {
> + if (c != 0)
> + return -EINVAL;
> + }
> + ret = process_access_response(group, &response, info_buf, c);
> if (ret < 0)
> count = ret;
>
> @@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> {
> struct fsnotify_group *group = file->private_data;
> struct fsnotify_event *fsn_event;
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_ALLOW };
>
> /*
> * Stop new events from arriving in the notification queue. since
> @@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> event = list_first_entry(&group->fanotify_data.access_list,
> struct fanotify_perm_event, fae.fse.list);
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, FAN_ALLOW);
> + finish_permission_event(group, event, &response, 0, NULL);
> spin_lock(&group->notification_lock);
> }
>
> @@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> fsnotify_destroy_event(group, fsn_event);
> } else {
> finish_permission_event(group, FANOTIFY_PERM(event),
> - FAN_ALLOW);
> + &response, 0, NULL);
> }
> spin_lock(&group->notification_lock);
> }
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index edc28555814c..ce9f97eb69f2 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -114,6 +114,11 @@
> #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
> FANOTIFY_EVENT_FLAGS)
>
> +/* This mask is to check for invalid bits of a user space permission response */
> +#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
> +#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
> +#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
> +
> /* Do not use these old uapi constants internally */
> #undef FAN_ALL_CLASS_BITS
> #undef FAN_ALL_INIT_FLAGS
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
> + */
> +
> +#define FAN_RESPONSE_INFO_NONE 0
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
> /* Legit userspace responses to a _PERM event */
> #define FAN_ALLOW 0x01
> #define FAN_DENY 0x02
> -#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
> +#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
> +#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
>
> /* No fd set in event */
> #define FAN_NOFD -1
> --
> 2.27.0
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-10 14:28 ` kernel test robot
-1 siblings, 0 replies; 91+ messages in thread
From: kernel test robot @ 2022-08-10 14:28 UTC (permalink / raw)
To: Richard Guy Briggs, Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: llvm, kbuild-all, Paul Moore, Eric Paris, Steve Grubb,
Richard Guy Briggs, Jan Kara, Amir Goldstein
Hi Richard,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on jack-fs/fsnotify]
[also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
git checkout a943676abc023c094f05b45f4d61936c567507a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
group, fd, response, info_buf, count);
^~~~~
include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
~~~ ^~~~~~~~~~~
include/linux/printk.h:464:60: note: expanded from macro 'printk'
#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
_p_func(_fmt, ##__VA_ARGS__); \
~~~~ ^~~~~~~~~~~
1 warning generated.
vim +325 fs/notify/fanotify/fanotify_user.c
312
313 static int process_access_response(struct fsnotify_group *group,
314 struct fanotify_response *response_struct,
315 const char __user *buf,
316 size_t count)
317 {
318 struct fanotify_perm_event *event;
319 int fd = response_struct->fd;
320 u32 response = response_struct->response;
321 struct fanotify_response_info_header info_hdr;
322 char *info_buf = NULL;
323
324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> 325 group, fd, response, info_buf, count);
326 /*
327 * make sure the response is valid, if invalid we do nothing and either
328 * userspace can send a valid response or we will clean it up after the
329 * timeout
330 */
331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
332 return -EINVAL;
333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
334 case FAN_ALLOW:
335 case FAN_DENY:
336 break;
337 default:
338 return -EINVAL;
339 }
340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
341 return -EINVAL;
342 if (fd < 0)
343 return -EINVAL;
344 if (response & FAN_INFO) {
345 size_t c = count;
346 const char __user *ib = buf;
347
348 if (c <= 0)
349 return -EINVAL;
350 while (c >= sizeof(info_hdr)) {
351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
352 return -EFAULT;
353 if (info_hdr.pad != 0)
354 return -EINVAL;
355 if (c < info_hdr.len)
356 return -EINVAL;
357 switch (info_hdr.type) {
358 case FAN_RESPONSE_INFO_AUDIT_RULE:
359 break;
360 case FAN_RESPONSE_INFO_NONE:
361 default:
362 return -EINVAL;
363 }
364 c -= info_hdr.len;
365 ib += info_hdr.len;
366 }
367 if (c != 0)
368 return -EINVAL;
369 /* Simplistic check for now */
370 if (count != sizeof(struct fanotify_response_info_audit_rule))
371 return -EINVAL;
372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
373 GFP_KERNEL);
374 if (!info_buf)
375 return -ENOMEM;
376 if (copy_from_user(info_buf, buf, count))
377 return -EFAULT;
378 }
379 spin_lock(&group->notification_lock);
380 list_for_each_entry(event, &group->fanotify_data.access_list,
381 fae.fse.list) {
382 if (event->fd != fd)
383 continue;
384
385 list_del_init(&event->fae.fse.list);
386 /* finish_permission_event() eats info_buf */
387 finish_permission_event(group, event, response_struct,
388 count, info_buf);
389 wake_up(&group->fanotify_data.access_waitq);
390 return 0;
391 }
392 spin_unlock(&group->notification_lock);
393
394 return -ENOENT;
395 }
396
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-10 14:28 ` kernel test robot
0 siblings, 0 replies; 91+ messages in thread
From: kernel test robot @ 2022-08-10 14:28 UTC (permalink / raw)
To: Richard Guy Briggs, Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Amir Goldstein, kbuild-all, Richard Guy Briggs, Jan Kara, llvm,
Eric Paris
Hi Richard,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on jack-fs/fsnotify]
[also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
git checkout a943676abc023c094f05b45f4d61936c567507a2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
group, fd, response, info_buf, count);
^~~~~
include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
~~~ ^~~~~~~~~~~
include/linux/printk.h:464:60: note: expanded from macro 'printk'
#define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
_p_func(_fmt, ##__VA_ARGS__); \
~~~~ ^~~~~~~~~~~
1 warning generated.
vim +325 fs/notify/fanotify/fanotify_user.c
312
313 static int process_access_response(struct fsnotify_group *group,
314 struct fanotify_response *response_struct,
315 const char __user *buf,
316 size_t count)
317 {
318 struct fanotify_perm_event *event;
319 int fd = response_struct->fd;
320 u32 response = response_struct->response;
321 struct fanotify_response_info_header info_hdr;
322 char *info_buf = NULL;
323
324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> 325 group, fd, response, info_buf, count);
326 /*
327 * make sure the response is valid, if invalid we do nothing and either
328 * userspace can send a valid response or we will clean it up after the
329 * timeout
330 */
331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
332 return -EINVAL;
333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
334 case FAN_ALLOW:
335 case FAN_DENY:
336 break;
337 default:
338 return -EINVAL;
339 }
340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
341 return -EINVAL;
342 if (fd < 0)
343 return -EINVAL;
344 if (response & FAN_INFO) {
345 size_t c = count;
346 const char __user *ib = buf;
347
348 if (c <= 0)
349 return -EINVAL;
350 while (c >= sizeof(info_hdr)) {
351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
352 return -EFAULT;
353 if (info_hdr.pad != 0)
354 return -EINVAL;
355 if (c < info_hdr.len)
356 return -EINVAL;
357 switch (info_hdr.type) {
358 case FAN_RESPONSE_INFO_AUDIT_RULE:
359 break;
360 case FAN_RESPONSE_INFO_NONE:
361 default:
362 return -EINVAL;
363 }
364 c -= info_hdr.len;
365 ib += info_hdr.len;
366 }
367 if (c != 0)
368 return -EINVAL;
369 /* Simplistic check for now */
370 if (count != sizeof(struct fanotify_response_info_audit_rule))
371 return -EINVAL;
372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
373 GFP_KERNEL);
374 if (!info_buf)
375 return -ENOMEM;
376 if (copy_from_user(info_buf, buf, count))
377 return -EFAULT;
378 }
379 spin_lock(&group->notification_lock);
380 list_for_each_entry(event, &group->fanotify_data.access_list,
381 fae.fse.list) {
382 if (event->fd != fd)
383 continue;
384
385 list_del_init(&event->fae.fse.list);
386 /* finish_permission_event() eats info_buf */
387 finish_permission_event(group, event, response_struct,
388 count, info_buf);
389 wake_up(&group->fanotify_data.access_waitq);
390 return 0;
391 }
392 spin_unlock(&group->notification_lock);
393
394 return -ENOENT;
395 }
396
--
0-DAY CI Kernel Test Service
https://01.org/lkp
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-10 19:15 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-10 19:15 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel, Richard Guy Briggs
Cc: Paul Moore, Eric Paris, Richard Guy Briggs, Jan Kara, Amir Goldstein
Hell Richard,
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> fan_info=3F
I compiled a new kernel and run old user space on this. The above event is
exactly what I see in my audit logs. Why the fan_info=3F? I really would have
expected 0. What if the actual rule number was 63? I think this will work
better to leave everything 0 with old user space.
-Steve
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?"
*/
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u
fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL,
AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u
fan_info=",
> + response, friar-
>hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE,
sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u
fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
@ 2022-08-10 19:15 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-10 19:15 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel, Richard Guy Briggs
Cc: Richard Guy Briggs, Eric Paris, Amir Goldstein, Jan Kara
Hell Richard,
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> fan_info=3F
I compiled a new kernel and run old user space on this. The above event is
exactly what I see in my audit logs. Why the fan_info=3F? I really would have
expected 0. What if the actual rule number was 63? I think this will work
better to leave everything 0 with old user space.
-Steve
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?"
*/
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u
fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL,
AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u
fan_info=",
> + response, friar-
>hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE,
sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u
fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-10 20:32 ` kernel test robot
-1 siblings, 0 replies; 91+ messages in thread
From: kernel test robot @ 2022-08-10 20:32 UTC (permalink / raw)
To: Richard Guy Briggs, Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: llvm, kbuild-all, Paul Moore, Eric Paris, Steve Grubb,
Richard Guy Briggs, Jan Kara, Amir Goldstein
Hi Richard,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on jack-fs/fsnotify]
[also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
config: x86_64-randconfig-a016 (https://download.01.org/0day-ci/archive/20220811/202208110406.Lb3ONrcP-lkp@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/bee8cac0b7796a753948c83b403a152f8c6acb8c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
git checkout bee8cac0b7796a753948c83b403a152f8c6acb8c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> kernel/auditsc.c:2907:8: warning: variable 'ib' set but not used [-Wunused-but-set-variable]
char *ib = buf;
^
1 warning generated.
vim +/ib +2907 kernel/auditsc.c
2902
2903 void __audit_fanotify(u32 response, size_t len, char *buf)
2904 {
2905 struct fanotify_response_info_audit_rule *friar;
2906 size_t c = len;
> 2907 char *ib = buf;
2908
2909 if (!(len && buf)) {
2910 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2911 "resp=%u fan_type=0 fan_info=?", response);
2912 return;
2913 }
2914 while (c >= sizeof(struct fanotify_response_info_header)) {
2915 friar = (struct fanotify_response_info_audit_rule *)buf;
2916 switch (friar->hdr.type) {
2917 case FAN_RESPONSE_INFO_AUDIT_RULE:
2918 if (friar->hdr.len < sizeof(*friar)) {
2919 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2920 "resp=%u fan_type=%u fan_info=(incomplete)",
2921 response, friar->hdr.type);
2922 return;
2923 }
2924 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2925 "resp=%u fan_type=%u fan_info=%u",
2926 response, friar->hdr.type, friar->audit_rule);
2927 }
2928 c -= friar->hdr.len;
2929 ib += friar->hdr.len;
2930 }
2931 }
2932
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-08-10 20:32 ` kernel test robot
0 siblings, 0 replies; 91+ messages in thread
From: kernel test robot @ 2022-08-10 20:32 UTC (permalink / raw)
To: Richard Guy Briggs, Linux-Audit Mailing List, LKML, linux-fsdevel
Cc: Amir Goldstein, kbuild-all, Richard Guy Briggs, Jan Kara, llvm,
Eric Paris
Hi Richard,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on jack-fs/fsnotify]
[also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
config: x86_64-randconfig-a016 (https://download.01.org/0day-ci/archive/20220811/202208110406.Lb3ONrcP-lkp@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/bee8cac0b7796a753948c83b403a152f8c6acb8c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
git checkout bee8cac0b7796a753948c83b403a152f8c6acb8c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> kernel/auditsc.c:2907:8: warning: variable 'ib' set but not used [-Wunused-but-set-variable]
char *ib = buf;
^
1 warning generated.
vim +/ib +2907 kernel/auditsc.c
2902
2903 void __audit_fanotify(u32 response, size_t len, char *buf)
2904 {
2905 struct fanotify_response_info_audit_rule *friar;
2906 size_t c = len;
> 2907 char *ib = buf;
2908
2909 if (!(len && buf)) {
2910 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2911 "resp=%u fan_type=0 fan_info=?", response);
2912 return;
2913 }
2914 while (c >= sizeof(struct fanotify_response_info_header)) {
2915 friar = (struct fanotify_response_info_audit_rule *)buf;
2916 switch (friar->hdr.type) {
2917 case FAN_RESPONSE_INFO_AUDIT_RULE:
2918 if (friar->hdr.len < sizeof(*friar)) {
2919 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2920 "resp=%u fan_type=%u fan_info=(incomplete)",
2921 response, friar->hdr.type);
2922 return;
2923 }
2924 audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
2925 "resp=%u fan_type=%u fan_info=%u",
2926 response, friar->hdr.type, friar->audit_rule);
2927 }
2928 c -= friar->hdr.len;
2929 ib += friar->hdr.len;
2930 }
2931 }
2932
--
0-DAY CI Kernel Test Service
https://01.org/lkp
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
2022-08-10 19:15 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
@ 2022-08-11 2:23 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-11 2:23 UTC (permalink / raw)
To: Steve Grubb
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Jan Kara, Amir Goldstein
On 2022-08-10 15:15, Steve Grubb wrote:
> Hell Richard,
That's quite an introduction! ;-)
> On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> > Currently the only type of fanotify info that is defined is an audit
> > rule number, but convert it to hex encoding to future-proof the field.
> >
> > Sample record:
> > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> > fan_info=3F
>
> I compiled a new kernel and run old user space on this. The above event is
> exactly what I see in my audit logs. Why the fan_info=3F? I really would have
> expected 0. What if the actual rule number was 63? I think this will work
> better to leave everything 0 with old user space.
Well, if it is to be consistently hex encoded, that corresponds to "?"
if it is to be interpreted as a string. Since the fan_type is 0,
fan_info would be invalid, so a value of 0 would be entirely reasonable,
hex encoded to fan_info=00. It could also be hex encoded to the string
"(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
that would be fan_info=30 if it were interpreted as a string, or
arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type
should determine how fan_info's hex encoded value should be interpreted.
But ultimately, the point of this patch is to hex encode the fan_info
field value.
> -Steve
>
> > Suggested-by: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/auditsc.c | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f000fec52360..0f747015c577 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> > char *buf)
> >
> > if (!(len && buf)) {
> > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=0 fan_info=?", response);
> > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> > return;
> > }
> > while (c >= sizeof(struct fanotify_response_info_header)) {
> > + struct audit_context *ctx = audit_context();
> > + struct audit_buffer *ab;
> > +
> > friar = (struct fanotify_response_info_audit_rule *)buf;
> > switch (friar->hdr.type) {
> > case FAN_RESPONSE_INFO_AUDIT_RULE:
> > if (friar->hdr.len < sizeof(*friar)) {
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=(incomplete)",
> > - response, friar->hdr.type);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar-
> >hdr.type);
> > +#define INCOMPLETE "(incomplete)"
> > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> > + audit_log_end(ab);
> > + }
> > return;
> > }
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=%u",
> > - response, friar->hdr.type, friar->audit_rule);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> > + sizeof(friar->audit_rule));
> > + audit_log_end(ab);
> > +
> > + }
> > }
> > c -= friar->hdr.len;
> > ib += friar->hdr.len;
>
>
>
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
@ 2022-08-11 2:23 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-11 2:23 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-08-10 15:15, Steve Grubb wrote:
> Hell Richard,
That's quite an introduction! ;-)
> On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> > Currently the only type of fanotify info that is defined is an audit
> > rule number, but convert it to hex encoding to future-proof the field.
> >
> > Sample record:
> > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> > fan_info=3F
>
> I compiled a new kernel and run old user space on this. The above event is
> exactly what I see in my audit logs. Why the fan_info=3F? I really would have
> expected 0. What if the actual rule number was 63? I think this will work
> better to leave everything 0 with old user space.
Well, if it is to be consistently hex encoded, that corresponds to "?"
if it is to be interpreted as a string. Since the fan_type is 0,
fan_info would be invalid, so a value of 0 would be entirely reasonable,
hex encoded to fan_info=00. It could also be hex encoded to the string
"(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
that would be fan_info=30 if it were interpreted as a string, or
arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type
should determine how fan_info's hex encoded value should be interpreted.
But ultimately, the point of this patch is to hex encode the fan_info
field value.
> -Steve
>
> > Suggested-by: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/auditsc.c | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f000fec52360..0f747015c577 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> > char *buf)
> >
> > if (!(len && buf)) {
> > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=0 fan_info=?", response);
> > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> > return;
> > }
> > while (c >= sizeof(struct fanotify_response_info_header)) {
> > + struct audit_context *ctx = audit_context();
> > + struct audit_buffer *ab;
> > +
> > friar = (struct fanotify_response_info_audit_rule *)buf;
> > switch (friar->hdr.type) {
> > case FAN_RESPONSE_INFO_AUDIT_RULE:
> > if (friar->hdr.len < sizeof(*friar)) {
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=(incomplete)",
> > - response, friar->hdr.type);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar-
> >hdr.type);
> > +#define INCOMPLETE "(incomplete)"
> > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> > + audit_log_end(ab);
> > + }
> > return;
> > }
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=%u",
> > - response, friar->hdr.type, friar->audit_rule);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> > + sizeof(friar->audit_rule));
> > + audit_log_end(ab);
> > +
> > + }
> > }
> > c -= friar->hdr.len;
> > ib += friar->hdr.len;
>
>
>
>
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-12 0:23 ` Matthew Bobrowski
-1 siblings, 0 replies; 91+ messages in thread
From: Matthew Bobrowski @ 2022-08-12 0:23 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Steve Grubb, Jan Kara, Amir Goldstein
On Tue, Aug 09, 2022 at 01:22:53PM -0400, Richard Guy Briggs wrote:
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
Just some comments/questions.
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 4f897e109547..0f36062521f4 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
> }
>
> /* userspace responded, convert to something usable */
> - switch (event->response & ~FAN_AUDIT) {
> + switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> ret = 0;
> break;
> case FAN_DENY:
> - default:
> ret = -EPERM;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
I'm definitely of the opinion that this shouldn't change as it
completely misrepresents why the acting process failed to perform
whatever operation it is intending to perform on the underlying
file.
Also, at this point, will we ever get into a situation where the
permission event was responded to using an invalid access response
flag? That is, if the event listener responds to a permission event
with something other than FAN_{ALLOW, DENY}, then it in turn already
receives an -EINVAL error. Having said that, I don't see how we'd ever
get to the point where the access list would contain a queued
permission event with an invalid response flag. I'm not saying that
this check should be dropped entirely, but rather returning -EINVAL
AFAICT to the actor process really doesn't make sense.
> /* Check if the response should be audited */
> @@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
>
> pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
> pevent->response = 0;
> + pevent->info_len = 0;
> + pevent->info_buf = NULL;
> pevent->state = FAN_EVENT_INIT;
> pevent->path = *path;
> path_get(path);
> @@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
> static void fanotify_free_perm_event(struct fanotify_event *event)
> {
> path_put(fanotify_event_path(event));
> + kfree(FANOTIFY_PERM(event)->info_buf);
> kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
> }
>
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
>
> static inline struct fanotify_perm_event *
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
> @@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
> }
>
> static int process_access_response(struct fsnotify_group *group,
> - struct fanotify_response *response_struct)
> + struct fanotify_response *response_struct,
> + const char __user *buf,
> + size_t count)
> {
> struct fanotify_perm_event *event;
> int fd = response_struct->fd;
> u32 response = response_struct->response;
> + struct fanotify_response_info_header info_hdr;
Why is this scoped at the function level?
> + char *info_buf = NULL;
>
> - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> - fd, response);
> + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> + group, fd, response, info_buf, count);
info_buf is NULL at this point, I think you meant buf,right? Also
s/size/count in the format string.
> /*
> * make sure the response is valid, if invalid we do nothing and either
> * userspace can send a valid response or we will clean it up after the
> * timeout
> */
> - switch (response & ~FAN_AUDIT) {
> + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> + return -EINVAL;
> + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> case FAN_DENY:
> break;
> default:
> return -EINVAL;
> }
> -
> - if (fd < 0)
> - return -EINVAL;
> -
> if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> return -EINVAL;
> + if (fd < 0)
> + return -EINVAL;
> + if (response & FAN_INFO) {
> + size_t c = count;
> + const char __user *ib = buf;
Again, can we use variable names that are a little bit more
meaningful? *ib specifically confuses me as I've already got *info_buf
from above in my head. Maybe *info would make more sense seeing as
though this is the FAN_INFO path?
> + If (c <= 0)
> + return -EINVAL;
Is this needed? We already perform checks on the supplied count in
fanotify_write()?
> + while (c >= sizeof(info_hdr)) {
> + if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> + return -EFAULT;
> + if (info_hdr.pad != 0)
> + return -EINVAL;
> + if (c < info_hdr.len)
> + return -EINVAL;
> + switch (info_hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + break;
> + case FAN_RESPONSE_INFO_NONE:
> + default:
> + return -EINVAL;
> + }
> + c -= info_hdr.len;
> + ib += info_hdr.len;
> + }
> + if (c != 0)
> + return -EINVAL;
> + /* Simplistic check for now */
> + if (count != sizeof(struct fanotify_response_info_audit_rule))
> + return -EINVAL;
I don't get why we perform this check here? If anything, I'd expect
this to be one of the first things we do when we step into this
branch. There's no point of pulling the info_hdr if count isn't what
we expect?
> + info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> + GFP_KERNEL);
> + if (!info_buf)
> + return -ENOMEM;
> + if (copy_from_user(info_buf, buf, count))
> + return -EFAULT;
> + }
MY. EYES. HURT! This block is rather difficult to read, so feel free
to add newlines when splitting this up into a helper.
> spin_lock(&group->notification_lock);
> list_for_each_entry(event, &group->fanotify_data.access_list,
> fae.fse.list) {
> @@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
> continue;
>
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, response);
> + /* finish_permission_event() eats info_buf */
What is this comment? Get rid of it.
> + finish_permission_event(group, event, response_struct,
> + count, info_buf);
> wake_up(&group->fanotify_data.access_waitq);
> return 0;
> }
> @@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> fsnotify_destroy_event(group, &event->fse);
> } else {
> if (ret <= 0) {
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_DENY };
> +
> spin_lock(&group->notification_lock);
> finish_permission_event(group,
> - FANOTIFY_PERM(event), FAN_DENY);
> + FANOTIFY_PERM(event), &response,
> + 0, NULL);
> wake_up(&group->fanotify_data.access_waitq);
> } else {
> spin_lock(&group->notification_lock);
> @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
>
> static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> {
> - struct fanotify_response response = { .fd = -1, .response = -1 };
> + struct fanotify_response response;
> struct fsnotify_group *group;
> int ret;
> + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> + size_t c;
Can we rename this to something like len or info_len instead? I
dislike single character variable names outside of the scope of things
like loops.
> if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> return -EINVAL;
>
> group = file->private_data;
>
> - if (count < sizeof(response))
> - return -EINVAL;
> -
> - count = sizeof(response);
> -
> pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
>
> - if (copy_from_user(&response, buf, count))
> + if (count < sizeof(response))
> + return -EINVAL;
> + if (copy_from_user(&response, buf, sizeof(response)))
> return -EFAULT;
>
> - ret = process_access_response(group, &response);
> + c = count - sizeof(response);
> + if (response.response & FAN_INFO) {
> + if (c < sizeof(struct fanotify_response_info_header))
> + return -EINVAL;
> + } else {
> + if (c != 0)
> + return -EINVAL;
Hm, prior to this change we truncated the copy operation to the
sizeof(struct fanotify_response) and didn't care if there maybe was
extra data supplied in the buf or count > sizeof(struct
fanotify_response). This leaves me wondering whether this check is
needed for cases that are not (FAN_INFO | FAN_AUDIT)? The buf may
still hold a valid fanotify_response despite buf/count possibly being
larger than sizeof(struct fanotify_response)... I can see why you'd
want to enforce this, but I'm wondering if it might break things if
event listeners are responding to the permission events in an awkward
way i.e. by calculating and supplying count incorrectly.
Also, if we do decide to keep this check around, then maybe it can be
simplified into an else if instead?
> + }
> + ret = process_access_response(group, &response, info_buf, c);
Can we add a newline above this call to process_access_response()?
> if (ret < 0)
> count = ret;
>
> @@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> {
> struct fsnotify_group *group = file->private_data;
> struct fsnotify_event *fsn_event;
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_ALLOW };
>
> /*
> * Stop new events from arriving in the notification queue. since
> @@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> event = list_first_entry(&group->fanotify_data.access_list,
> struct fanotify_perm_event, fae.fse.list);
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, FAN_ALLOW);
> + finish_permission_event(group, event, &response, 0, NULL);
> spin_lock(&group->notification_lock);
> }
>
> @@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> fsnotify_destroy_event(group, fsn_event);
> } else {
> finish_permission_event(group, FANOTIFY_PERM(event),
> - FAN_ALLOW);
> + &response, 0, NULL);
> }
> spin_lock(&group->notification_lock);
> }
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index edc28555814c..ce9f97eb69f2 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -114,6 +114,11 @@
> #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
> FANOTIFY_EVENT_FLAGS)
>
> +/* This mask is to check for invalid bits of a user space permission response */
These masks are used across checks which involve permission responses.
> +#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
> +#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
> +#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
> +
> /* Do not use these old uapi constants internally */
> #undef FAN_ALL_CLASS_BITS
> #undef FAN_ALL_INIT_FLAGS
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
I'm actually confused by this last paragraph. What is "context type"
and what is "Rule"? Do you mean the struct
fanotify_response_info_header.type and the audit_rule that follows?
> +#define FAN_RESPONSE_INFO_NONE 0
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
> /* Legit userspace responses to a _PERM event */
> #define FAN_ALLOW 0x01
> #define FAN_DENY 0x02
> -#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
> +#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
> +#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
>
> /* No fd set in event */
> #define FAN_NOFD -1
> --
> 2.27.0
>
/M
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-12 0:23 ` Matthew Bobrowski
0 siblings, 0 replies; 91+ messages in thread
From: Matthew Bobrowski @ 2022-08-12 0:23 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Tue, Aug 09, 2022 at 01:22:53PM -0400, Richard Guy Briggs wrote:
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
Just some comments/questions.
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 4f897e109547..0f36062521f4 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group,
> }
>
> /* userspace responded, convert to something usable */
> - switch (event->response & ~FAN_AUDIT) {
> + switch (event->response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> ret = 0;
> break;
> case FAN_DENY:
> - default:
> ret = -EPERM;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
I'm definitely of the opinion that this shouldn't change as it
completely misrepresents why the acting process failed to perform
whatever operation it is intending to perform on the underlying
file.
Also, at this point, will we ever get into a situation where the
permission event was responded to using an invalid access response
flag? That is, if the event listener responds to a permission event
with something other than FAN_{ALLOW, DENY}, then it in turn already
receives an -EINVAL error. Having said that, I don't see how we'd ever
get to the point where the access list would contain a queued
permission event with an invalid response flag. I'm not saying that
this check should be dropped entirely, but rather returning -EINVAL
AFAICT to the actor process really doesn't make sense.
> /* Check if the response should be audited */
> @@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path,
>
> pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM;
> pevent->response = 0;
> + pevent->info_len = 0;
> + pevent->info_buf = NULL;
> pevent->state = FAN_EVENT_INIT;
> pevent->path = *path;
> path_get(path);
> @@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event)
> static void fanotify_free_perm_event(struct fanotify_event *event)
> {
> path_put(fanotify_event_path(event));
> + kfree(FANOTIFY_PERM(event)->info_buf);
> kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event));
> }
>
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
>
> static inline struct fanotify_perm_event *
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
> @@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group,
> }
>
> static int process_access_response(struct fsnotify_group *group,
> - struct fanotify_response *response_struct)
> + struct fanotify_response *response_struct,
> + const char __user *buf,
> + size_t count)
> {
> struct fanotify_perm_event *event;
> int fd = response_struct->fd;
> u32 response = response_struct->response;
> + struct fanotify_response_info_header info_hdr;
Why is this scoped at the function level?
> + char *info_buf = NULL;
>
> - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> - fd, response);
> + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> + group, fd, response, info_buf, count);
info_buf is NULL at this point, I think you meant buf,right? Also
s/size/count in the format string.
> /*
> * make sure the response is valid, if invalid we do nothing and either
> * userspace can send a valid response or we will clean it up after the
> * timeout
> */
> - switch (response & ~FAN_AUDIT) {
> + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> + return -EINVAL;
> + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> case FAN_ALLOW:
> case FAN_DENY:
> break;
> default:
> return -EINVAL;
> }
> -
> - if (fd < 0)
> - return -EINVAL;
> -
> if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> return -EINVAL;
> + if (fd < 0)
> + return -EINVAL;
> + if (response & FAN_INFO) {
> + size_t c = count;
> + const char __user *ib = buf;
Again, can we use variable names that are a little bit more
meaningful? *ib specifically confuses me as I've already got *info_buf
from above in my head. Maybe *info would make more sense seeing as
though this is the FAN_INFO path?
> + If (c <= 0)
> + return -EINVAL;
Is this needed? We already perform checks on the supplied count in
fanotify_write()?
> + while (c >= sizeof(info_hdr)) {
> + if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> + return -EFAULT;
> + if (info_hdr.pad != 0)
> + return -EINVAL;
> + if (c < info_hdr.len)
> + return -EINVAL;
> + switch (info_hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + break;
> + case FAN_RESPONSE_INFO_NONE:
> + default:
> + return -EINVAL;
> + }
> + c -= info_hdr.len;
> + ib += info_hdr.len;
> + }
> + if (c != 0)
> + return -EINVAL;
> + /* Simplistic check for now */
> + if (count != sizeof(struct fanotify_response_info_audit_rule))
> + return -EINVAL;
I don't get why we perform this check here? If anything, I'd expect
this to be one of the first things we do when we step into this
branch. There's no point of pulling the info_hdr if count isn't what
we expect?
> + info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> + GFP_KERNEL);
> + if (!info_buf)
> + return -ENOMEM;
> + if (copy_from_user(info_buf, buf, count))
> + return -EFAULT;
> + }
MY. EYES. HURT! This block is rather difficult to read, so feel free
to add newlines when splitting this up into a helper.
> spin_lock(&group->notification_lock);
> list_for_each_entry(event, &group->fanotify_data.access_list,
> fae.fse.list) {
> @@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group,
> continue;
>
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, response);
> + /* finish_permission_event() eats info_buf */
What is this comment? Get rid of it.
> + finish_permission_event(group, event, response_struct,
> + count, info_buf);
> wake_up(&group->fanotify_data.access_waitq);
> return 0;
> }
> @@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> fsnotify_destroy_event(group, &event->fse);
> } else {
> if (ret <= 0) {
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_DENY };
> +
> spin_lock(&group->notification_lock);
> finish_permission_event(group,
> - FANOTIFY_PERM(event), FAN_DENY);
> + FANOTIFY_PERM(event), &response,
> + 0, NULL);
> wake_up(&group->fanotify_data.access_waitq);
> } else {
> spin_lock(&group->notification_lock);
> @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
>
> static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> {
> - struct fanotify_response response = { .fd = -1, .response = -1 };
> + struct fanotify_response response;
> struct fsnotify_group *group;
> int ret;
> + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> + size_t c;
Can we rename this to something like len or info_len instead? I
dislike single character variable names outside of the scope of things
like loops.
> if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> return -EINVAL;
>
> group = file->private_data;
>
> - if (count < sizeof(response))
> - return -EINVAL;
> -
> - count = sizeof(response);
> -
> pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
>
> - if (copy_from_user(&response, buf, count))
> + if (count < sizeof(response))
> + return -EINVAL;
> + if (copy_from_user(&response, buf, sizeof(response)))
> return -EFAULT;
>
> - ret = process_access_response(group, &response);
> + c = count - sizeof(response);
> + if (response.response & FAN_INFO) {
> + if (c < sizeof(struct fanotify_response_info_header))
> + return -EINVAL;
> + } else {
> + if (c != 0)
> + return -EINVAL;
Hm, prior to this change we truncated the copy operation to the
sizeof(struct fanotify_response) and didn't care if there maybe was
extra data supplied in the buf or count > sizeof(struct
fanotify_response). This leaves me wondering whether this check is
needed for cases that are not (FAN_INFO | FAN_AUDIT)? The buf may
still hold a valid fanotify_response despite buf/count possibly being
larger than sizeof(struct fanotify_response)... I can see why you'd
want to enforce this, but I'm wondering if it might break things if
event listeners are responding to the permission events in an awkward
way i.e. by calculating and supplying count incorrectly.
Also, if we do decide to keep this check around, then maybe it can be
simplified into an else if instead?
> + }
> + ret = process_access_response(group, &response, info_buf, c);
Can we add a newline above this call to process_access_response()?
> if (ret < 0)
> count = ret;
>
> @@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> {
> struct fsnotify_group *group = file->private_data;
> struct fsnotify_event *fsn_event;
> + struct fanotify_response response = {
> + .fd = FAN_NOFD,
> + .response = FAN_ALLOW };
>
> /*
> * Stop new events from arriving in the notification queue. since
> @@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> event = list_first_entry(&group->fanotify_data.access_list,
> struct fanotify_perm_event, fae.fse.list);
> list_del_init(&event->fae.fse.list);
> - finish_permission_event(group, event, FAN_ALLOW);
> + finish_permission_event(group, event, &response, 0, NULL);
> spin_lock(&group->notification_lock);
> }
>
> @@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file)
> fsnotify_destroy_event(group, fsn_event);
> } else {
> finish_permission_event(group, FANOTIFY_PERM(event),
> - FAN_ALLOW);
> + &response, 0, NULL);
> }
> spin_lock(&group->notification_lock);
> }
> diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
> index edc28555814c..ce9f97eb69f2 100644
> --- a/include/linux/fanotify.h
> +++ b/include/linux/fanotify.h
> @@ -114,6 +114,11 @@
> #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
> FANOTIFY_EVENT_FLAGS)
>
> +/* This mask is to check for invalid bits of a user space permission response */
These masks are used across checks which involve permission responses.
> +#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY)
> +#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO)
> +#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS)
> +
> /* Do not use these old uapi constants internally */
> #undef FAN_ALL_CLASS_BITS
> #undef FAN_ALL_INIT_FLAGS
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
I'm actually confused by this last paragraph. What is "context type"
and what is "Rule"? Do you mean the struct
fanotify_response_info_header.type and the audit_rule that follows?
> +#define FAN_RESPONSE_INFO_NONE 0
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
> /* Legit userspace responses to a _PERM event */
> #define FAN_ALLOW 0x01
> #define FAN_DENY 0x02
> -#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
> +#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */
> +#define FAN_INFO 0x20 /* Bitmask to indicate additional information */
>
> /* No fd set in event */
> #define FAN_NOFD -1
> --
> 2.27.0
>
/M
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
2022-08-11 2:23 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-15 21:15 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-15 21:15 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
Hello Richard,
On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote:
> > I compiled a new kernel and run old user space on this. The above event
> > is
> > exactly what I see in my audit logs. Why the fan_info=3F? I really would
> > have expected 0. What if the actual rule number was 63? I think this
> > will work better to leave everything 0 with old user space.
>
> Well, if it is to be consistently hex encoded, that corresponds to "?"
I suppose this OK.
> if it is to be interpreted as a string. Since the fan_type is 0,
> fan_info would be invalid, so a value of 0 would be entirely reasonable,
> hex encoded to fan_info=00. It could also be hex encoded to the string
> "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
> that would be fan_info=30 if it were interpreted as a string, or
> arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type
> should determine how fan_info's hex encoded value should be interpreted.
>
> But ultimately, the point of this patch is to hex encode the fan_info
> field value.
Just one last update, I have been able to test the patches with the user
space application and it appears to be working from the PoV of what is sent
is what's in the audit logs. I'm not sure how picky old kernels are wrt the
size of what's sent. But an unpatched 5.19 kernel seems to accept the larger
size response and do the right thing.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
@ 2022-08-15 21:15 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-15 21:15 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Jan Kara, Amir Goldstein
Hello Richard,
On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote:
> > I compiled a new kernel and run old user space on this. The above event
> > is
> > exactly what I see in my audit logs. Why the fan_info=3F? I really would
> > have expected 0. What if the actual rule number was 63? I think this
> > will work better to leave everything 0 with old user space.
>
> Well, if it is to be consistently hex encoded, that corresponds to "?"
I suppose this OK.
> if it is to be interpreted as a string. Since the fan_type is 0,
> fan_info would be invalid, so a value of 0 would be entirely reasonable,
> hex encoded to fan_info=00. It could also be hex encoded to the string
> "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE,
> that would be fan_info=30 if it were interpreted as a string, or
> arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type
> should determine how fan_info's hex encoded value should be interpreted.
>
> But ultimately, the point of this patch is to hex encode the fan_info
> field value.
Just one last update, I have been able to test the patches with the user
space application and it appears to be working from the PoV of what is sent
is what's in the audit logs. I'm not sure how picky old kernels are wrt the
size of what's sent. But an unpatched 5.19 kernel seems to accept the larger
size response and do the right thing.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-16 0:22 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-08-16 0:22 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> This patch passes the full value so that the audit function can use all
> of it. The audit function was updated to log the additional information in
> the AUDIT_FANOTIFY record. The following is an example of the new record
> format:
>
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> fs/notify/fanotify/fanotify.c | 3 ++-
> include/linux/audit.h | 9 +++++----
> kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
> 3 files changed, 35 insertions(+), 8 deletions(-)
You've hopefully already seen the kernel test robot build warning, so
I won't bring that up again, but a few comments below ...
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 0f36062521f4..36c3ed1af085 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -276,7 +276,8 @@ static int fanotify_get_response(struct fsnotify_group *group,
>
> /* Check if the response should be audited */
> if (event->response & FAN_AUDIT)
> - audit_fanotify(event->response & ~FAN_AUDIT);
> + audit_fanotify(event->response & ~FAN_AUDIT,
> + event->info_len, event->info_buf);
>
> pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
> group, event, ret);
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 3ea198a2cd59..c69efdba12ca 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -14,6 +14,7 @@
> #include <linux/audit_arch.h>
> #include <uapi/linux/audit.h>
> #include <uapi/linux/netfilter/nf_tables.h>
> +#include <uapi/linux/fanotify.h>
>
> #define AUDIT_INO_UNSET ((unsigned long)-1)
> #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -417,7 +418,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
> extern void __audit_mmap_fd(int fd, int flags);
> extern void __audit_openat2_how(struct open_how *how);
> extern void __audit_log_kern_module(char *name);
> -extern void __audit_fanotify(u32 response);
> +extern void __audit_fanotify(u32 response, size_t len, char *buf);
> extern void __audit_tk_injoffset(struct timespec64 offset);
> extern void __audit_ntp_log(const struct audit_ntp_data *ad);
> extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
> @@ -524,10 +525,10 @@ static inline void audit_log_kern_module(char *name)
> __audit_log_kern_module(name);
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, size_t len, char *buf)
> {
> if (!audit_dummy_context())
> - __audit_fanotify(response);
> + __audit_fanotify(response, len, buf);
> }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> @@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name)
> {
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, size_t len, char *buf)
> { }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 433418d73584..f000fec52360 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
> #include <uapi/linux/limits.h>
> #include <uapi/linux/netfilter/nf_tables.h>
> #include <uapi/linux/openat2.h> // struct open_how
> +#include <uapi/linux/fanotify.h>
>
> #include "audit.h"
>
> @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> context->type = AUDIT_KERN_MODULE;
> }
>
> -void __audit_fanotify(u32 response)
> +void __audit_fanotify(u32 response, size_t len, char *buf)
> {
> - audit_log(audit_context(), GFP_KERNEL,
> - AUDIT_FANOTIFY, "resp=%u", response);
> + struct fanotify_response_info_audit_rule *friar;
> + size_t c = len;
> + char *ib = buf;
> +
> + if (!(len && buf)) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=0 fan_info=?", response);
> + return;
> + }
> + while (c >= sizeof(struct fanotify_response_info_header)) {
> + friar = (struct fanotify_response_info_audit_rule *)buf;
Since the only use of this at the moment is the
fanotify_response_info_rule, why not pass the
fanotify_response_info_rule struct directly into this function? We
can always change it if we need to in the future without affecting
userspace, and it would simplify the code.
> + switch (friar->hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + if (friar->hdr.len < sizeof(*friar)) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u fan_info=(incomplete)",
> + response, friar->hdr.type);
> + return;
> + }
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u fan_info=%u",
> + response, friar->hdr.type, friar->audit_rule);
> + }
> + c -= friar->hdr.len;
> + ib += friar->hdr.len;
> + }
> }
>
> void __audit_tk_injoffset(struct timespec64 offset)
> --
> 2.27.0
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-08-16 0:22 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-08-16 0:22 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Steve Grubb, Jan Kara, Amir Goldstein
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> This patch passes the full value so that the audit function can use all
> of it. The audit function was updated to log the additional information in
> the AUDIT_FANOTIFY record. The following is an example of the new record
> format:
>
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> fs/notify/fanotify/fanotify.c | 3 ++-
> include/linux/audit.h | 9 +++++----
> kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
> 3 files changed, 35 insertions(+), 8 deletions(-)
You've hopefully already seen the kernel test robot build warning, so
I won't bring that up again, but a few comments below ...
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 0f36062521f4..36c3ed1af085 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -276,7 +276,8 @@ static int fanotify_get_response(struct fsnotify_group *group,
>
> /* Check if the response should be audited */
> if (event->response & FAN_AUDIT)
> - audit_fanotify(event->response & ~FAN_AUDIT);
> + audit_fanotify(event->response & ~FAN_AUDIT,
> + event->info_len, event->info_buf);
>
> pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
> group, event, ret);
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 3ea198a2cd59..c69efdba12ca 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -14,6 +14,7 @@
> #include <linux/audit_arch.h>
> #include <uapi/linux/audit.h>
> #include <uapi/linux/netfilter/nf_tables.h>
> +#include <uapi/linux/fanotify.h>
>
> #define AUDIT_INO_UNSET ((unsigned long)-1)
> #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -417,7 +418,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old);
> extern void __audit_mmap_fd(int fd, int flags);
> extern void __audit_openat2_how(struct open_how *how);
> extern void __audit_log_kern_module(char *name);
> -extern void __audit_fanotify(u32 response);
> +extern void __audit_fanotify(u32 response, size_t len, char *buf);
> extern void __audit_tk_injoffset(struct timespec64 offset);
> extern void __audit_ntp_log(const struct audit_ntp_data *ad);
> extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries,
> @@ -524,10 +525,10 @@ static inline void audit_log_kern_module(char *name)
> __audit_log_kern_module(name);
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, size_t len, char *buf)
> {
> if (!audit_dummy_context())
> - __audit_fanotify(response);
> + __audit_fanotify(response, len, buf);
> }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> @@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name)
> {
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, size_t len, char *buf)
> { }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 433418d73584..f000fec52360 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
> #include <uapi/linux/limits.h>
> #include <uapi/linux/netfilter/nf_tables.h>
> #include <uapi/linux/openat2.h> // struct open_how
> +#include <uapi/linux/fanotify.h>
>
> #include "audit.h"
>
> @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> context->type = AUDIT_KERN_MODULE;
> }
>
> -void __audit_fanotify(u32 response)
> +void __audit_fanotify(u32 response, size_t len, char *buf)
> {
> - audit_log(audit_context(), GFP_KERNEL,
> - AUDIT_FANOTIFY, "resp=%u", response);
> + struct fanotify_response_info_audit_rule *friar;
> + size_t c = len;
> + char *ib = buf;
> +
> + if (!(len && buf)) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=0 fan_info=?", response);
> + return;
> + }
> + while (c >= sizeof(struct fanotify_response_info_header)) {
> + friar = (struct fanotify_response_info_audit_rule *)buf;
Since the only use of this at the moment is the
fanotify_response_info_rule, why not pass the
fanotify_response_info_rule struct directly into this function? We
can always change it if we need to in the future without affecting
userspace, and it would simplify the code.
> + switch (friar->hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + if (friar->hdr.len < sizeof(*friar)) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u fan_info=(incomplete)",
> + response, friar->hdr.type);
> + return;
> + }
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u fan_info=%u",
> + response, friar->hdr.type, friar->audit_rule);
> + }
> + c -= friar->hdr.len;
> + ib += friar->hdr.len;
> + }
> }
>
> void __audit_tk_injoffset(struct timespec64 offset)
> --
> 2.27.0
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-16 0:31 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-08-16 0:31 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F
>
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
This needs to be squashed with patch 3/4; it's a user visible change
so we don't want someone backporting 3/4 without 4/4, especially when
it is part of the same patchset.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
Please drop the trailing comment, it's not necessary and it makes the
code messier.
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
Is the distinction between "?" and "(incomplete)" really that
important? I'm not going to go digging through all of the
audit_log_format() callers to check, but I believe there is precedence
for using "?" not only for when a value is missing, but when it is
bogus as well.
If we are really going to use "(incomplete)" here, let's do a better
job than defining a macro mid-function and only using it in one other
place - the line immediately below the definition. This is both ugly
and a little silly (especially when one considers that the macro name
is almost exactly the same as the string it replaces. If we must use
"(incomplete)" here, just ditch the macro; any conceptual arguments
about macros vs literals is largely rendered moot since there is only
one user.
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
> --
> 2.27.0
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
@ 2022-08-16 0:31 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-08-16 0:31 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Steve Grubb, Jan Kara, Amir Goldstein
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F
>
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
This needs to be squashed with patch 3/4; it's a user visible change
so we don't want someone backporting 3/4 without 4/4, especially when
it is part of the same patchset.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
Please drop the trailing comment, it's not necessary and it makes the
code messier.
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
Is the distinction between "?" and "(incomplete)" really that
important? I'm not going to go digging through all of the
audit_log_format() callers to check, but I believe there is precedence
for using "?" not only for when a value is missing, but when it is
bogus as well.
If we are really going to use "(incomplete)" here, let's do a better
job than defining a macro mid-function and only using it in one other
place - the line immediately below the definition. This is both ugly
and a little silly (especially when one considers that the macro name
is almost exactly the same as the string it replaces. If we must use
"(incomplete)" here, just ditch the macro; any conceptual arguments
about macros vs literals is largely rendered moot since there is only
one user.
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
> --
> 2.27.0
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
@ 2022-08-16 13:37 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-16 13:37 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel, Richard Guy Briggs
Cc: Paul Moore, Eric Paris, Richard Guy Briggs, Jan Kara, Amir Goldstein
Hello Richard,
Although I have it working, I have some comments below that might improve
things.
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> fan_info=3F
>
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
One thing to point out, the structure has a member audit_rule. It is
probably better to call it rule_number. This is because it has nothing to
do with any actual audit rule. It is a rule number meant to be recorded by
the audit system.
Also, that member is a __u32 type. Hex encoding that directly gives back a
__u32 when decoded - which is a bit unexpected since everything else is
strings. It would be better to convert the u32 to a base 10 string and then
hex encode that. A buffer of 12 bytes should be sufficient.
Thanks,
-Steve
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
@ 2022-08-16 13:37 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-16 13:37 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML, linux-fsdevel, Richard Guy Briggs
Cc: Richard Guy Briggs, Eric Paris, Amir Goldstein, Jan Kara
Hello Richard,
Although I have it working, I have some comments below that might improve
things.
On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
>
> Sample record:
> type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> fan_info=3F
>
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f000fec52360..0f747015c577 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> char *buf)
>
> if (!(len && buf)) {
> audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=0 fan_info=?", response);
> + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> return;
> }
> while (c >= sizeof(struct fanotify_response_info_header)) {
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> +
> friar = (struct fanotify_response_info_audit_rule *)buf;
> switch (friar->hdr.type) {
> case FAN_RESPONSE_INFO_AUDIT_RULE:
> if (friar->hdr.len < sizeof(*friar)) {
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=(incomplete)",
> - response, friar->hdr.type);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> +#define INCOMPLETE "(incomplete)"
> + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> + audit_log_end(ab);
> + }
> return;
> }
> - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> - "resp=%u fan_type=%u fan_info=%u",
> - response, friar->hdr.type, friar->audit_rule);
> + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> + if (ab) {
> + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> + response, friar->hdr.type);
> + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> + sizeof(friar->audit_rule));
One thing to point out, the structure has a member audit_rule. It is
probably better to call it rule_number. This is because it has nothing to
do with any actual audit rule. It is a rule number meant to be recorded by
the audit system.
Also, that member is a __u32 type. Hex encoding that directly gives back a
__u32 when decoded - which is a bit unexpected since everything else is
strings. It would be better to convert the u32 to a base 10 string and then
hex encode that. A buffer of 12 bytes should be sufficient.
Thanks,
-Steve
> + audit_log_end(ab);
> +
> + }
> }
> c -= friar->hdr.len;
> ib += friar->hdr.len;
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-09 17:22 ` Richard Guy Briggs
@ 2022-08-19 11:13 ` Jan Kara
-1 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:13 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Steve Grubb, Jan Kara, Amir Goldstein
Hello Richard!
On Tue 09-08-22 13:22:53, Richard Guy Briggs wrote:
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
Amir and Matthew covered most of the comments so let me add just a few I
have on top:
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
Rather than this, I'd expand struct fanotify_perm_event by adding:
union info {
struct fanotify_response_info_header hdr;
struct fanotify_response_info_audit_rule audit_rule;
}
at the end of the struct. Currently that is more memory efficient, easier
to code, and more CPU efficient as well. The 'hdr' member of the union can
be used to look at type of the info and then appropriate union member can
be used to get the data. If we ever grow additional info that has
non-trivial size, changing the code to use dynamically allocated buffer as
you do now is very easy. But until that moment it is just overengineering.
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
Why do you pass struct fanotify_response here instead of plain u32? I don't
see you'd use it anywhere and it introduces some unnecessary churn in other
places.
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
Why do you mask out FAN_INFO here? I don't see a good reason for that.
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
...
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
> + */
> +
> +#define FAN_RESPONSE_INFO_NONE 0
Why do you define this? I don't see it being used anywhere (in a meaningful
way). You can as well make FAN_RESPONSE_INFO_AUDIT_RULE be type 0...
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 11:13 ` Jan Kara
0 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:13 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
Hello Richard!
On Tue 09-08-22 13:22:53, Richard Guy Briggs wrote:
> This patch adds a flag, FAN_INFO and an extensible buffer to provide
> additional information about response decisions. The buffer contains
> one or more headers defining the information type and the length of the
> following information. The patch defines one additional information
> type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> allow for the creation of other information types in the future if other
> users of the API identify different needs.
>
> Suggested-by: Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> Suggested-by: Jan Kara <jack@suse.cz>
> Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> fs/notify/fanotify/fanotify.c | 10 ++-
> fs/notify/fanotify/fanotify.h | 2 +
> fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------
> include/linux/fanotify.h | 5 ++
> include/uapi/linux/fanotify.h | 27 +++++++-
> 5 files changed, 123 insertions(+), 25 deletions(-)
Amir and Matthew covered most of the comments so let me add just a few I
have on top:
> diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> index abfa3712c185..14c30e173632 100644
> --- a/fs/notify/fanotify/fanotify.h
> +++ b/fs/notify/fanotify/fanotify.h
> @@ -428,6 +428,8 @@ struct fanotify_perm_event {
> u32 response; /* userspace answer to the event */
> unsigned short state; /* state of the event */
> int fd; /* fd we passed to userspace for this event */
> + size_t info_len;
> + char *info_buf;
> };
Rather than this, I'd expand struct fanotify_perm_event by adding:
union info {
struct fanotify_response_info_header hdr;
struct fanotify_response_info_audit_rule audit_rule;
}
at the end of the struct. Currently that is more memory efficient, easier
to code, and more CPU efficient as well. The 'hdr' member of the union can
be used to look at type of the info and then appropriate union member can
be used to get the data. If we ever grow additional info that has
non-trivial size, changing the code to use dynamically allocated buffer as
you do now is very easy. But until that moment it is just overengineering.
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ff67ca0d25cc..a4ae953f0e62 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
> */
> static void finish_permission_event(struct fsnotify_group *group,
> struct fanotify_perm_event *event,
> - u32 response)
> + struct fanotify_response *response,
Why do you pass struct fanotify_response here instead of plain u32? I don't
see you'd use it anywhere and it introduces some unnecessary churn in other
places.
> + size_t info_len, char *info_buf)
> __releases(&group->notification_lock)
> {
> bool destroy = false;
>
> assert_spin_locked(&group->notification_lock);
> - event->response = response;
> + event->response = response->response & ~FAN_INFO;
Why do you mask out FAN_INFO here? I don't see a good reason for that.
> + if (response->response & FAN_INFO) {
> + event->info_len = info_len;
> + event->info_buf = info_buf;
> + }
> if (event->state == FAN_EVENT_CANCELED)
> destroy = true;
> else
...
> diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
> index f1f89132d60e..4d08823a5698 100644
> --- a/include/uapi/linux/fanotify.h
> +++ b/include/uapi/linux/fanotify.h
> @@ -180,15 +180,40 @@ struct fanotify_event_info_error {
> __u32 error_count;
> };
>
> +/*
> + * User space may need to record additional information about its decision.
> + * The extra information type records what kind of information is included.
> + * The default is none. We also define an extra information buffer whose
> + * size is determined by the extra information type.
> + *
> + * If the context type is Rule, then the context following is the rule number
> + * that triggered the user space decision.
> + */
> +
> +#define FAN_RESPONSE_INFO_NONE 0
Why do you define this? I don't see it being used anywhere (in a meaningful
way). You can as well make FAN_RESPONSE_INFO_AUDIT_RULE be type 0...
> +#define FAN_RESPONSE_INFO_AUDIT_RULE 1
> +
> struct fanotify_response {
> __s32 fd;
> __u32 response;
> };
>
> +struct fanotify_response_info_header {
> + __u8 type;
> + __u8 pad;
> + __u16 len;
> +};
> +
> +struct fanotify_response_info_audit_rule {
> + struct fanotify_response_info_header hdr;
> + __u32 audit_rule;
> +};
> +
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-12 0:23 ` Matthew Bobrowski
@ 2022-08-19 11:16 ` Jan Kara
-1 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:16 UTC (permalink / raw)
To: Matthew Bobrowski
Cc: Richard Guy Briggs, Linux-Audit Mailing List, LKML,
linux-fsdevel, Paul Moore, Eric Paris, Steve Grubb, Jan Kara,
Amir Goldstein
On Fri 12-08-22 10:23:13, Matthew Bobrowski wrote:
> On Tue, Aug 09, 2022 at 01:22:53PM -0400, Richard Guy Briggs wrote:
> > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > additional information about response decisions. The buffer contains
> > one or more headers defining the information type and the length of the
> > following information. The patch defines one additional information
> > type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> > allow for the creation of other information types in the future if other
> > users of the API identify different needs.
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
...
> > @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> >
> > static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> > {
> > - struct fanotify_response response = { .fd = -1, .response = -1 };
> > + struct fanotify_response response;
> > struct fsnotify_group *group;
> > int ret;
> > + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> > + size_t c;
>
> Can we rename this to something like len or info_len instead? I
> dislike single character variable names outside of the scope of things
> like loops.
>
> > if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> > return -EINVAL;
> >
> > group = file->private_data;
> >
> > - if (count < sizeof(response))
> > - return -EINVAL;
> > -
> > - count = sizeof(response);
> > -
> > pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
> >
> > - if (copy_from_user(&response, buf, count))
> > + if (count < sizeof(response))
> > + return -EINVAL;
> > + if (copy_from_user(&response, buf, sizeof(response)))
> > return -EFAULT;
> >
> > - ret = process_access_response(group, &response);
> > + c = count - sizeof(response);
> > + if (response.response & FAN_INFO) {
> > + if (c < sizeof(struct fanotify_response_info_header))
> > + return -EINVAL;
> > + } else {
> > + if (c != 0)
> > + return -EINVAL;
>
> Hm, prior to this change we truncated the copy operation to the
> sizeof(struct fanotify_response) and didn't care if there maybe was
> extra data supplied in the buf or count > sizeof(struct
> fanotify_response). This leaves me wondering whether this check is
> needed for cases that are not (FAN_INFO | FAN_AUDIT)? The buf may
> still hold a valid fanotify_response despite buf/count possibly being
> larger than sizeof(struct fanotify_response)... I can see why you'd
> want to enforce this, but I'm wondering if it might break things if
> event listeners are responding to the permission events in an awkward
> way i.e. by calculating and supplying count incorrectly.
>
> Also, if we do decide to keep this check around, then maybe it can be
> simplified into an else if instead?
So the check for (c != 0) in case FAN_INFO is not set is definitely asking
for userspace regression because before we have been just silently ignoring
additional bytes beyond standard reply. So please keep the old behavior of
ignoring extra bytes if FAN_INFO flag is not set. Thanks!
Honza
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 11:16 ` Jan Kara
0 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:16 UTC (permalink / raw)
To: Matthew Bobrowski
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Fri 12-08-22 10:23:13, Matthew Bobrowski wrote:
> On Tue, Aug 09, 2022 at 01:22:53PM -0400, Richard Guy Briggs wrote:
> > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > additional information about response decisions. The buffer contains
> > one or more headers defining the information type and the length of the
> > following information. The patch defines one additional information
> > type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> > allow for the creation of other information types in the future if other
> > users of the API identify different needs.
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
...
> > @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf,
> >
> > static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> > {
> > - struct fanotify_response response = { .fd = -1, .response = -1 };
> > + struct fanotify_response response;
> > struct fsnotify_group *group;
> > int ret;
> > + const char __user *info_buf = buf + sizeof(struct fanotify_response);
> > + size_t c;
>
> Can we rename this to something like len or info_len instead? I
> dislike single character variable names outside of the scope of things
> like loops.
>
> > if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS))
> > return -EINVAL;
> >
> > group = file->private_data;
> >
> > - if (count < sizeof(response))
> > - return -EINVAL;
> > -
> > - count = sizeof(response);
> > -
> > pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
> >
> > - if (copy_from_user(&response, buf, count))
> > + if (count < sizeof(response))
> > + return -EINVAL;
> > + if (copy_from_user(&response, buf, sizeof(response)))
> > return -EFAULT;
> >
> > - ret = process_access_response(group, &response);
> > + c = count - sizeof(response);
> > + if (response.response & FAN_INFO) {
> > + if (c < sizeof(struct fanotify_response_info_header))
> > + return -EINVAL;
> > + } else {
> > + if (c != 0)
> > + return -EINVAL;
>
> Hm, prior to this change we truncated the copy operation to the
> sizeof(struct fanotify_response) and didn't care if there maybe was
> extra data supplied in the buf or count > sizeof(struct
> fanotify_response). This leaves me wondering whether this check is
> needed for cases that are not (FAN_INFO | FAN_AUDIT)? The buf may
> still hold a valid fanotify_response despite buf/count possibly being
> larger than sizeof(struct fanotify_response)... I can see why you'd
> want to enforce this, but I'm wondering if it might break things if
> event listeners are responding to the permission events in an awkward
> way i.e. by calculating and supplying count incorrectly.
>
> Also, if we do decide to keep this check around, then maybe it can be
> simplified into an else if instead?
So the check for (c != 0) in case FAN_INFO is not set is definitely asking
for userspace regression because before we have been just silently ignoring
additional bytes beyond standard reply. So please keep the old behavior of
ignoring extra bytes if FAN_INFO flag is not set. Thanks!
Honza
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-10 6:22 ` Amir Goldstein
@ 2022-08-19 11:24 ` Jan Kara
-1 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:24 UTC (permalink / raw)
To: Amir Goldstein
Cc: Richard Guy Briggs, Linux-Audit Mailing List, LKML,
linux-fsdevel, Paul Moore, Eric Paris, Steve Grubb, Jan Kara,
Linux API
On Wed 10-08-22 08:22:49, Amir Goldstein wrote:
> [+linux-api]
>
> On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > additional information about response decisions. The buffer contains
> > one or more headers defining the information type and the length of the
> > following information. The patch defines one additional information
> > type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> > allow for the creation of other information types in the future if other
> > users of the API identify different needs.
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
...
> > static int process_access_response(struct fsnotify_group *group,
> > - struct fanotify_response *response_struct)
> > + struct fanotify_response *response_struct,
> > + const char __user *buf,
> > + size_t count)
> > {
> > struct fanotify_perm_event *event;
> > int fd = response_struct->fd;
> > u32 response = response_struct->response;
> > + struct fanotify_response_info_header info_hdr;
> > + char *info_buf = NULL;
> >
> > - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> > - fd, response);
> > + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > + group, fd, response, info_buf, count);
> > /*
> > * make sure the response is valid, if invalid we do nothing and either
> > * userspace can send a valid response or we will clean it up after the
> > * timeout
> > */
> > - switch (response & ~FAN_AUDIT) {
> > + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > + return -EINVAL;
> > + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > case FAN_ALLOW:
> > case FAN_DENY:
> > break;
> > default:
> > return -EINVAL;
> > }
> > -
> > - if (fd < 0)
> > - return -EINVAL;
> > -
> > if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > return -EINVAL;
> > + if (fd < 0)
> > + return -EINVAL;
>
> Since you did not accept my suggestion of FAN_TEST [1],
> I am not sure why this check was moved.
>
> However, if you move this check past FAN_INFO processing,
> you could change the error value to -ENOENT, same as the return value
> for an fd that is >= 0 but does not correspond to any pending
> permission event.
>
> The idea was that userspace could write a test
> fanotify_response_info_audit_rule payload to fanotify fd with FAN_NOFD
> in the response.fd field.
> On old kernel, this will return EINVAL.
> On new kernel, if the fanotify_response_info_audit_rule payload
> passes all the validations, this will do nothing and return ENOENT.
>
> [1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
Yes. Richard, if you don't like the FAN_TEST proposal from Amir, please
explain (preferably also with sample code) how you imagine userspace will
decide whether to use FAN_INFO flag in responses or not. Because if it will
just blindly set it, that will result in all permission events to finished
with EPERM for kernels not recognizing FAN_INFO.
> > - if (count < sizeof(response))
> > - return -EINVAL;
> > -
> > - count = sizeof(response);
> > -
> > pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
> >
> > - if (copy_from_user(&response, buf, count))
> > + if (count < sizeof(response))
> > + return -EINVAL;
> > + if (copy_from_user(&response, buf, sizeof(response)))
> > return -EFAULT;
> >
> > - ret = process_access_response(group, &response);
> > + c = count - sizeof(response);
> > + if (response.response & FAN_INFO) {
> > + if (c < sizeof(struct fanotify_response_info_header))
> > + return -EINVAL;
>
> Should FAN_INFO require FAN_AUDIT?
Currently we could but longer term not all additional info needs to be
related to audit so probably I'd not require that even now (which results
in info being effectively ignored after it is parsed).
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 11:24 ` Jan Kara
0 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-08-19 11:24 UTC (permalink / raw)
To: Amir Goldstein
Cc: Jan Kara, Richard Guy Briggs, Linux API, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Wed 10-08-22 08:22:49, Amir Goldstein wrote:
> [+linux-api]
>
> On Tue, Aug 9, 2022 at 7:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > This patch adds a flag, FAN_INFO and an extensible buffer to provide
> > additional information about response decisions. The buffer contains
> > one or more headers defining the information type and the length of the
> > following information. The patch defines one additional information
> > type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will
> > allow for the creation of other information types in the future if other
> > users of the API identify different needs.
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2
> > Suggested-by: Jan Kara <jack@suse.cz>
> > Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
...
> > static int process_access_response(struct fsnotify_group *group,
> > - struct fanotify_response *response_struct)
> > + struct fanotify_response *response_struct,
> > + const char __user *buf,
> > + size_t count)
> > {
> > struct fanotify_perm_event *event;
> > int fd = response_struct->fd;
> > u32 response = response_struct->response;
> > + struct fanotify_response_info_header info_hdr;
> > + char *info_buf = NULL;
> >
> > - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group,
> > - fd, response);
> > + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > + group, fd, response, info_buf, count);
> > /*
> > * make sure the response is valid, if invalid we do nothing and either
> > * userspace can send a valid response or we will clean it up after the
> > * timeout
> > */
> > - switch (response & ~FAN_AUDIT) {
> > + if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > + return -EINVAL;
> > + switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > case FAN_ALLOW:
> > case FAN_DENY:
> > break;
> > default:
> > return -EINVAL;
> > }
> > -
> > - if (fd < 0)
> > - return -EINVAL;
> > -
> > if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > return -EINVAL;
> > + if (fd < 0)
> > + return -EINVAL;
>
> Since you did not accept my suggestion of FAN_TEST [1],
> I am not sure why this check was moved.
>
> However, if you move this check past FAN_INFO processing,
> you could change the error value to -ENOENT, same as the return value
> for an fd that is >= 0 but does not correspond to any pending
> permission event.
>
> The idea was that userspace could write a test
> fanotify_response_info_audit_rule payload to fanotify fd with FAN_NOFD
> in the response.fd field.
> On old kernel, this will return EINVAL.
> On new kernel, if the fanotify_response_info_audit_rule payload
> passes all the validations, this will do nothing and return ENOENT.
>
> [1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxi+8HUqyGxQBNMqSong92nreOWLKdy9MCrYg8wgW9Dj4g@mail.gmail.com/
Yes. Richard, if you don't like the FAN_TEST proposal from Amir, please
explain (preferably also with sample code) how you imagine userspace will
decide whether to use FAN_INFO flag in responses or not. Because if it will
just blindly set it, that will result in all permission events to finished
with EPERM for kernels not recognizing FAN_INFO.
> > - if (count < sizeof(response))
> > - return -EINVAL;
> > -
> > - count = sizeof(response);
> > -
> > pr_debug("%s: group=%p count=%zu\n", __func__, group, count);
> >
> > - if (copy_from_user(&response, buf, count))
> > + if (count < sizeof(response))
> > + return -EINVAL;
> > + if (copy_from_user(&response, buf, sizeof(response)))
> > return -EFAULT;
> >
> > - ret = process_access_response(group, &response);
> > + c = count - sizeof(response);
> > + if (response.response & FAN_INFO) {
> > + if (c < sizeof(struct fanotify_response_info_header))
> > + return -EINVAL;
>
> Should FAN_INFO require FAN_AUDIT?
Currently we could but longer term not all additional info needs to be
related to audit so probably I'd not require that even now (which results
in info being effectively ignored after it is parsed).
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-10 14:28 ` kernel test robot
(?)
@ 2022-08-19 16:25 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 16:25 UTC (permalink / raw)
To: kernel test robot
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, llvm, kbuild-all,
Paul Moore, Eric Paris, Steve Grubb, Jan Kara, Amir Goldstein
On 2022-08-10 22:28, kernel test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on jack-fs/fsnotify]
> [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> git checkout a943676abc023c094f05b45f4d61936c567507a2
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
Interesting. When I "fix" it, my compiler complains:
fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
> group, fd, response, info_buf, count);
> ^~~~~
> include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> printk(fmt, ##__VA_ARGS__); \
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:464:60: note: expanded from macro 'printk'
> #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> _p_func(_fmt, ##__VA_ARGS__); \
> ~~~~ ^~~~~~~~~~~
> 1 warning generated.
>
>
> vim +325 fs/notify/fanotify/fanotify_user.c
>
> 312
> 313 static int process_access_response(struct fsnotify_group *group,
> 314 struct fanotify_response *response_struct,
> 315 const char __user *buf,
> 316 size_t count)
> 317 {
> 318 struct fanotify_perm_event *event;
> 319 int fd = response_struct->fd;
> 320 u32 response = response_struct->response;
> 321 struct fanotify_response_info_header info_hdr;
> 322 char *info_buf = NULL;
> 323
> 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > 325 group, fd, response, info_buf, count);
> 326 /*
> 327 * make sure the response is valid, if invalid we do nothing and either
> 328 * userspace can send a valid response or we will clean it up after the
> 329 * timeout
> 330 */
> 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> 332 return -EINVAL;
> 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> 334 case FAN_ALLOW:
> 335 case FAN_DENY:
> 336 break;
> 337 default:
> 338 return -EINVAL;
> 339 }
> 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> 341 return -EINVAL;
> 342 if (fd < 0)
> 343 return -EINVAL;
> 344 if (response & FAN_INFO) {
> 345 size_t c = count;
> 346 const char __user *ib = buf;
> 347
> 348 if (c <= 0)
> 349 return -EINVAL;
> 350 while (c >= sizeof(info_hdr)) {
> 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> 352 return -EFAULT;
> 353 if (info_hdr.pad != 0)
> 354 return -EINVAL;
> 355 if (c < info_hdr.len)
> 356 return -EINVAL;
> 357 switch (info_hdr.type) {
> 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> 359 break;
> 360 case FAN_RESPONSE_INFO_NONE:
> 361 default:
> 362 return -EINVAL;
> 363 }
> 364 c -= info_hdr.len;
> 365 ib += info_hdr.len;
> 366 }
> 367 if (c != 0)
> 368 return -EINVAL;
> 369 /* Simplistic check for now */
> 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> 371 return -EINVAL;
> 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> 373 GFP_KERNEL);
> 374 if (!info_buf)
> 375 return -ENOMEM;
> 376 if (copy_from_user(info_buf, buf, count))
> 377 return -EFAULT;
> 378 }
> 379 spin_lock(&group->notification_lock);
> 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> 381 fae.fse.list) {
> 382 if (event->fd != fd)
> 383 continue;
> 384
> 385 list_del_init(&event->fae.fse.list);
> 386 /* finish_permission_event() eats info_buf */
> 387 finish_permission_event(group, event, response_struct,
> 388 count, info_buf);
> 389 wake_up(&group->fanotify_data.access_waitq);
> 390 return 0;
> 391 }
> 392 spin_unlock(&group->notification_lock);
> 393
> 394 return -ENOENT;
> 395 }
> 396
>
> --
> 0-DAY CI Kernel Test Service
> https://01.org/lkp
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 16:25 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 16:25 UTC (permalink / raw)
To: kernel test robot
Cc: Amir Goldstein, kbuild-all, Jan Kara, llvm, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On 2022-08-10 22:28, kernel test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on jack-fs/fsnotify]
> [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> git checkout a943676abc023c094f05b45f4d61936c567507a2
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
Interesting. When I "fix" it, my compiler complains:
fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
> group, fd, response, info_buf, count);
> ^~~~~
> include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> printk(fmt, ##__VA_ARGS__); \
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:464:60: note: expanded from macro 'printk'
> #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> _p_func(_fmt, ##__VA_ARGS__); \
> ~~~~ ^~~~~~~~~~~
> 1 warning generated.
>
>
> vim +325 fs/notify/fanotify/fanotify_user.c
>
> 312
> 313 static int process_access_response(struct fsnotify_group *group,
> 314 struct fanotify_response *response_struct,
> 315 const char __user *buf,
> 316 size_t count)
> 317 {
> 318 struct fanotify_perm_event *event;
> 319 int fd = response_struct->fd;
> 320 u32 response = response_struct->response;
> 321 struct fanotify_response_info_header info_hdr;
> 322 char *info_buf = NULL;
> 323
> 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > 325 group, fd, response, info_buf, count);
> 326 /*
> 327 * make sure the response is valid, if invalid we do nothing and either
> 328 * userspace can send a valid response or we will clean it up after the
> 329 * timeout
> 330 */
> 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> 332 return -EINVAL;
> 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> 334 case FAN_ALLOW:
> 335 case FAN_DENY:
> 336 break;
> 337 default:
> 338 return -EINVAL;
> 339 }
> 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> 341 return -EINVAL;
> 342 if (fd < 0)
> 343 return -EINVAL;
> 344 if (response & FAN_INFO) {
> 345 size_t c = count;
> 346 const char __user *ib = buf;
> 347
> 348 if (c <= 0)
> 349 return -EINVAL;
> 350 while (c >= sizeof(info_hdr)) {
> 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> 352 return -EFAULT;
> 353 if (info_hdr.pad != 0)
> 354 return -EINVAL;
> 355 if (c < info_hdr.len)
> 356 return -EINVAL;
> 357 switch (info_hdr.type) {
> 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> 359 break;
> 360 case FAN_RESPONSE_INFO_NONE:
> 361 default:
> 362 return -EINVAL;
> 363 }
> 364 c -= info_hdr.len;
> 365 ib += info_hdr.len;
> 366 }
> 367 if (c != 0)
> 368 return -EINVAL;
> 369 /* Simplistic check for now */
> 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> 371 return -EINVAL;
> 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> 373 GFP_KERNEL);
> 374 if (!info_buf)
> 375 return -ENOMEM;
> 376 if (copy_from_user(info_buf, buf, count))
> 377 return -EFAULT;
> 378 }
> 379 spin_lock(&group->notification_lock);
> 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> 381 fae.fse.list) {
> 382 if (event->fd != fd)
> 383 continue;
> 384
> 385 list_del_init(&event->fae.fse.list);
> 386 /* finish_permission_event() eats info_buf */
> 387 finish_permission_event(group, event, response_struct,
> 388 count, info_buf);
> 389 wake_up(&group->fanotify_data.access_waitq);
> 390 return 0;
> 391 }
> 392 spin_unlock(&group->notification_lock);
> 393
> 394 return -ENOENT;
> 395 }
> 396
>
> --
> 0-DAY CI Kernel Test Service
> https://01.org/lkp
>
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 16:25 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 16:25 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 6754 bytes --]
On 2022-08-10 22:28, kernel test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on jack-fs/fsnotify]
> [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp(a)intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> git checkout a943676abc023c094f05b45f4d61936c567507a2
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
Interesting. When I "fix" it, my compiler complains:
fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
> group, fd, response, info_buf, count);
> ^~~~~
> include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> printk(fmt, ##__VA_ARGS__); \
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:464:60: note: expanded from macro 'printk'
> #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> ~~~ ^~~~~~~~~~~
> include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> _p_func(_fmt, ##__VA_ARGS__); \
> ~~~~ ^~~~~~~~~~~
> 1 warning generated.
>
>
> vim +325 fs/notify/fanotify/fanotify_user.c
>
> 312
> 313 static int process_access_response(struct fsnotify_group *group,
> 314 struct fanotify_response *response_struct,
> 315 const char __user *buf,
> 316 size_t count)
> 317 {
> 318 struct fanotify_perm_event *event;
> 319 int fd = response_struct->fd;
> 320 u32 response = response_struct->response;
> 321 struct fanotify_response_info_header info_hdr;
> 322 char *info_buf = NULL;
> 323
> 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > 325 group, fd, response, info_buf, count);
> 326 /*
> 327 * make sure the response is valid, if invalid we do nothing and either
> 328 * userspace can send a valid response or we will clean it up after the
> 329 * timeout
> 330 */
> 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> 332 return -EINVAL;
> 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> 334 case FAN_ALLOW:
> 335 case FAN_DENY:
> 336 break;
> 337 default:
> 338 return -EINVAL;
> 339 }
> 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> 341 return -EINVAL;
> 342 if (fd < 0)
> 343 return -EINVAL;
> 344 if (response & FAN_INFO) {
> 345 size_t c = count;
> 346 const char __user *ib = buf;
> 347
> 348 if (c <= 0)
> 349 return -EINVAL;
> 350 while (c >= sizeof(info_hdr)) {
> 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> 352 return -EFAULT;
> 353 if (info_hdr.pad != 0)
> 354 return -EINVAL;
> 355 if (c < info_hdr.len)
> 356 return -EINVAL;
> 357 switch (info_hdr.type) {
> 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> 359 break;
> 360 case FAN_RESPONSE_INFO_NONE:
> 361 default:
> 362 return -EINVAL;
> 363 }
> 364 c -= info_hdr.len;
> 365 ib += info_hdr.len;
> 366 }
> 367 if (c != 0)
> 368 return -EINVAL;
> 369 /* Simplistic check for now */
> 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> 371 return -EINVAL;
> 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> 373 GFP_KERNEL);
> 374 if (!info_buf)
> 375 return -ENOMEM;
> 376 if (copy_from_user(info_buf, buf, count))
> 377 return -EFAULT;
> 378 }
> 379 spin_lock(&group->notification_lock);
> 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> 381 fae.fse.list) {
> 382 if (event->fd != fd)
> 383 continue;
> 384
> 385 list_del_init(&event->fae.fse.list);
> 386 /* finish_permission_event() eats info_buf */
> 387 finish_permission_event(group, event, response_struct,
> 388 count, info_buf);
> 389 wake_up(&group->fanotify_data.access_waitq);
> 390 return 0;
> 391 }
> 392 spin_unlock(&group->notification_lock);
> 393
> 394 return -ENOENT;
> 395 }
> 396
>
> --
> 0-DAY CI Kernel Test Service
> https://01.org/lkp
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-19 16:25 ` Richard Guy Briggs
(?)
@ 2022-08-19 17:17 ` Nick Desaulniers
-1 siblings, 0 replies; 91+ messages in thread
From: Nick Desaulniers @ 2022-08-19 17:17 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: kernel test robot, Linux-Audit Mailing List, LKML, linux-fsdevel,
llvm, kbuild-all, Paul Moore, Eric Paris, Steve Grubb, Jan Kara,
Amir Goldstein
On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> On 2022-08-10 22:28, kernel test robot wrote:
> > Hi Richard,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on jack-fs/fsnotify]
> > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
>
> Interesting. When I "fix" it, my compiler complains:
>
> fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
The correct format specifier for size_t is %zu. This avoids issues
between ILP32 vs LP64 targets.
>
> > group, fd, response, info_buf, count);
> > ^~~~~
> > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > printk(fmt, ##__VA_ARGS__); \
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > _p_func(_fmt, ##__VA_ARGS__); \
> > ~~~~ ^~~~~~~~~~~
> > 1 warning generated.
> >
> >
> > vim +325 fs/notify/fanotify/fanotify_user.c
> >
> > 312
> > 313 static int process_access_response(struct fsnotify_group *group,
> > 314 struct fanotify_response *response_struct,
> > 315 const char __user *buf,
> > 316 size_t count)
> > 317 {
> > 318 struct fanotify_perm_event *event;
> > 319 int fd = response_struct->fd;
> > 320 u32 response = response_struct->response;
> > 321 struct fanotify_response_info_header info_hdr;
> > 322 char *info_buf = NULL;
> > 323
> > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > 325 group, fd, response, info_buf, count);
> > 326 /*
> > 327 * make sure the response is valid, if invalid we do nothing and either
> > 328 * userspace can send a valid response or we will clean it up after the
> > 329 * timeout
> > 330 */
> > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > 332 return -EINVAL;
> > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > 334 case FAN_ALLOW:
> > 335 case FAN_DENY:
> > 336 break;
> > 337 default:
> > 338 return -EINVAL;
> > 339 }
> > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > 341 return -EINVAL;
> > 342 if (fd < 0)
> > 343 return -EINVAL;
> > 344 if (response & FAN_INFO) {
> > 345 size_t c = count;
> > 346 const char __user *ib = buf;
> > 347
> > 348 if (c <= 0)
> > 349 return -EINVAL;
> > 350 while (c >= sizeof(info_hdr)) {
> > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > 352 return -EFAULT;
> > 353 if (info_hdr.pad != 0)
> > 354 return -EINVAL;
> > 355 if (c < info_hdr.len)
> > 356 return -EINVAL;
> > 357 switch (info_hdr.type) {
> > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > 359 break;
> > 360 case FAN_RESPONSE_INFO_NONE:
> > 361 default:
> > 362 return -EINVAL;
> > 363 }
> > 364 c -= info_hdr.len;
> > 365 ib += info_hdr.len;
> > 366 }
> > 367 if (c != 0)
> > 368 return -EINVAL;
> > 369 /* Simplistic check for now */
> > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > 371 return -EINVAL;
> > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > 373 GFP_KERNEL);
> > 374 if (!info_buf)
> > 375 return -ENOMEM;
> > 376 if (copy_from_user(info_buf, buf, count))
> > 377 return -EFAULT;
> > 378 }
> > 379 spin_lock(&group->notification_lock);
> > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > 381 fae.fse.list) {
> > 382 if (event->fd != fd)
> > 383 continue;
> > 384
> > 385 list_del_init(&event->fae.fse.list);
> > 386 /* finish_permission_event() eats info_buf */
> > 387 finish_permission_event(group, event, response_struct,
> > 388 count, info_buf);
> > 389 wake_up(&group->fanotify_data.access_waitq);
> > 390 return 0;
> > 391 }
> > 392 spin_unlock(&group->notification_lock);
> > 393
> > 394 return -ENOENT;
> > 395 }
> > 396
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://01.org/lkp
> >
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@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
>
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 17:17 ` Nick Desaulniers
0 siblings, 0 replies; 91+ messages in thread
From: Nick Desaulniers @ 2022-08-19 17:17 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Amir Goldstein, kbuild-all, kernel test robot, Jan Kara, llvm,
LKML, Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> On 2022-08-10 22:28, kernel test robot wrote:
> > Hi Richard,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on jack-fs/fsnotify]
> > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
>
> Interesting. When I "fix" it, my compiler complains:
>
> fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
The correct format specifier for size_t is %zu. This avoids issues
between ILP32 vs LP64 targets.
>
> > group, fd, response, info_buf, count);
> > ^~~~~
> > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > printk(fmt, ##__VA_ARGS__); \
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > _p_func(_fmt, ##__VA_ARGS__); \
> > ~~~~ ^~~~~~~~~~~
> > 1 warning generated.
> >
> >
> > vim +325 fs/notify/fanotify/fanotify_user.c
> >
> > 312
> > 313 static int process_access_response(struct fsnotify_group *group,
> > 314 struct fanotify_response *response_struct,
> > 315 const char __user *buf,
> > 316 size_t count)
> > 317 {
> > 318 struct fanotify_perm_event *event;
> > 319 int fd = response_struct->fd;
> > 320 u32 response = response_struct->response;
> > 321 struct fanotify_response_info_header info_hdr;
> > 322 char *info_buf = NULL;
> > 323
> > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > 325 group, fd, response, info_buf, count);
> > 326 /*
> > 327 * make sure the response is valid, if invalid we do nothing and either
> > 328 * userspace can send a valid response or we will clean it up after the
> > 329 * timeout
> > 330 */
> > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > 332 return -EINVAL;
> > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > 334 case FAN_ALLOW:
> > 335 case FAN_DENY:
> > 336 break;
> > 337 default:
> > 338 return -EINVAL;
> > 339 }
> > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > 341 return -EINVAL;
> > 342 if (fd < 0)
> > 343 return -EINVAL;
> > 344 if (response & FAN_INFO) {
> > 345 size_t c = count;
> > 346 const char __user *ib = buf;
> > 347
> > 348 if (c <= 0)
> > 349 return -EINVAL;
> > 350 while (c >= sizeof(info_hdr)) {
> > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > 352 return -EFAULT;
> > 353 if (info_hdr.pad != 0)
> > 354 return -EINVAL;
> > 355 if (c < info_hdr.len)
> > 356 return -EINVAL;
> > 357 switch (info_hdr.type) {
> > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > 359 break;
> > 360 case FAN_RESPONSE_INFO_NONE:
> > 361 default:
> > 362 return -EINVAL;
> > 363 }
> > 364 c -= info_hdr.len;
> > 365 ib += info_hdr.len;
> > 366 }
> > 367 if (c != 0)
> > 368 return -EINVAL;
> > 369 /* Simplistic check for now */
> > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > 371 return -EINVAL;
> > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > 373 GFP_KERNEL);
> > 374 if (!info_buf)
> > 375 return -ENOMEM;
> > 376 if (copy_from_user(info_buf, buf, count))
> > 377 return -EFAULT;
> > 378 }
> > 379 spin_lock(&group->notification_lock);
> > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > 381 fae.fse.list) {
> > 382 if (event->fd != fd)
> > 383 continue;
> > 384
> > 385 list_del_init(&event->fae.fse.list);
> > 386 /* finish_permission_event() eats info_buf */
> > 387 finish_permission_event(group, event, response_struct,
> > 388 count, info_buf);
> > 389 wake_up(&group->fanotify_data.access_waitq);
> > 390 return 0;
> > 391 }
> > 392 spin_unlock(&group->notification_lock);
> > 393
> > 394 return -ENOENT;
> > 395 }
> > 396
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://01.org/lkp
> >
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@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
>
>
--
Thanks,
~Nick Desaulniers
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 17:17 ` Nick Desaulniers
0 siblings, 0 replies; 91+ messages in thread
From: Nick Desaulniers @ 2022-08-19 17:17 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 8974 bytes --]
On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
>
> On 2022-08-10 22:28, kernel test robot wrote:
> > Hi Richard,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on jack-fs/fsnotify]
> > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp(a)intel.com/config)
> > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
>
> Interesting. When I "fix" it, my compiler complains:
>
> fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
The correct format specifier for size_t is %zu. This avoids issues
between ILP32 vs LP64 targets.
>
> > group, fd, response, info_buf, count);
> > ^~~~~
> > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > printk(fmt, ##__VA_ARGS__); \
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > ~~~ ^~~~~~~~~~~
> > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > _p_func(_fmt, ##__VA_ARGS__); \
> > ~~~~ ^~~~~~~~~~~
> > 1 warning generated.
> >
> >
> > vim +325 fs/notify/fanotify/fanotify_user.c
> >
> > 312
> > 313 static int process_access_response(struct fsnotify_group *group,
> > 314 struct fanotify_response *response_struct,
> > 315 const char __user *buf,
> > 316 size_t count)
> > 317 {
> > 318 struct fanotify_perm_event *event;
> > 319 int fd = response_struct->fd;
> > 320 u32 response = response_struct->response;
> > 321 struct fanotify_response_info_header info_hdr;
> > 322 char *info_buf = NULL;
> > 323
> > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > 325 group, fd, response, info_buf, count);
> > 326 /*
> > 327 * make sure the response is valid, if invalid we do nothing and either
> > 328 * userspace can send a valid response or we will clean it up after the
> > 329 * timeout
> > 330 */
> > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > 332 return -EINVAL;
> > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > 334 case FAN_ALLOW:
> > 335 case FAN_DENY:
> > 336 break;
> > 337 default:
> > 338 return -EINVAL;
> > 339 }
> > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > 341 return -EINVAL;
> > 342 if (fd < 0)
> > 343 return -EINVAL;
> > 344 if (response & FAN_INFO) {
> > 345 size_t c = count;
> > 346 const char __user *ib = buf;
> > 347
> > 348 if (c <= 0)
> > 349 return -EINVAL;
> > 350 while (c >= sizeof(info_hdr)) {
> > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > 352 return -EFAULT;
> > 353 if (info_hdr.pad != 0)
> > 354 return -EINVAL;
> > 355 if (c < info_hdr.len)
> > 356 return -EINVAL;
> > 357 switch (info_hdr.type) {
> > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > 359 break;
> > 360 case FAN_RESPONSE_INFO_NONE:
> > 361 default:
> > 362 return -EINVAL;
> > 363 }
> > 364 c -= info_hdr.len;
> > 365 ib += info_hdr.len;
> > 366 }
> > 367 if (c != 0)
> > 368 return -EINVAL;
> > 369 /* Simplistic check for now */
> > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > 371 return -EINVAL;
> > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > 373 GFP_KERNEL);
> > 374 if (!info_buf)
> > 375 return -ENOMEM;
> > 376 if (copy_from_user(info_buf, buf, count))
> > 377 return -EFAULT;
> > 378 }
> > 379 spin_lock(&group->notification_lock);
> > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > 381 fae.fse.list) {
> > 382 if (event->fd != fd)
> > 383 continue;
> > 384
> > 385 list_del_init(&event->fae.fse.list);
> > 386 /* finish_permission_event() eats info_buf */
> > 387 finish_permission_event(group, event, response_struct,
> > 388 count, info_buf);
> > 389 wake_up(&group->fanotify_data.access_waitq);
> > 390 return 0;
> > 391 }
> > 392 spin_unlock(&group->notification_lock);
> > 393
> > 394 return -ENOENT;
> > 395 }
> > 396
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://01.org/lkp
> >
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@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
>
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
2022-08-16 13:37 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
@ 2022-08-19 21:42 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 21:42 UTC (permalink / raw)
To: Steve Grubb
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Paul Moore,
Eric Paris, Jan Kara, Amir Goldstein
On 2022-08-16 09:37, Steve Grubb wrote:
> Hello Richard,
>
> Although I have it working, I have some comments below that might improve
> things.
>
> On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> > Currently the only type of fanotify info that is defined is an audit
> > rule number, but convert it to hex encoding to future-proof the field.
> >
> > Sample record:
> > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> > fan_info=3F
> >
> > Suggested-by: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/auditsc.c | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f000fec52360..0f747015c577 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> > char *buf)
> >
> > if (!(len && buf)) {
> > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=0 fan_info=?", response);
> > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> > return;
> > }
> > while (c >= sizeof(struct fanotify_response_info_header)) {
> > + struct audit_context *ctx = audit_context();
> > + struct audit_buffer *ab;
> > +
> > friar = (struct fanotify_response_info_audit_rule *)buf;
> > switch (friar->hdr.type) {
> > case FAN_RESPONSE_INFO_AUDIT_RULE:
> > if (friar->hdr.len < sizeof(*friar)) {
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=(incomplete)",
> > - response, friar->hdr.type);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > +#define INCOMPLETE "(incomplete)"
> > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> > + audit_log_end(ab);
> > + }
> > return;
> > }
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=%u",
> > - response, friar->hdr.type, friar->audit_rule);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> > + sizeof(friar->audit_rule));
>
> One thing to point out, the structure has a member audit_rule. It is
> probably better to call it rule_number. This is because it has nothing to
> do with any actual audit rule. It is a rule number meant to be recorded by
> the audit system.
>
> Also, that member is a __u32 type. Hex encoding that directly gives back a
> __u32 when decoded - which is a bit unexpected since everything else is
> strings. It would be better to convert the u32 to a base 10 string and then
> hex encode that. A buffer of 12 bytes should be sufficient.
Sure, these seem reasonable.
> Thanks,
> -Steve
>
> > + audit_log_end(ab);
> > +
> > + }
> > }
> > c -= friar->hdr.len;
> > ib += friar->hdr.len;
>
>
>
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string
@ 2022-08-19 21:42 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 21:42 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-08-16 09:37, Steve Grubb wrote:
> Hello Richard,
>
> Although I have it working, I have some comments below that might improve
> things.
>
> On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote:
> > Currently the only type of fanotify info that is defined is an audit
> > rule number, but convert it to hex encoding to future-proof the field.
> >
> > Sample record:
> > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0
> > fan_info=3F
> >
> > Suggested-by: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > kernel/auditsc.c | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f000fec52360..0f747015c577 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len,
> > char *buf)
> >
> > if (!(len && buf)) {
> > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=0 fan_info=?", response);
> > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */
> > return;
> > }
> > while (c >= sizeof(struct fanotify_response_info_header)) {
> > + struct audit_context *ctx = audit_context();
> > + struct audit_buffer *ab;
> > +
> > friar = (struct fanotify_response_info_audit_rule *)buf;
> > switch (friar->hdr.type) {
> > case FAN_RESPONSE_INFO_AUDIT_RULE:
> > if (friar->hdr.len < sizeof(*friar)) {
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=(incomplete)",
> > - response, friar->hdr.type);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > +#define INCOMPLETE "(incomplete)"
> > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE));
> > + audit_log_end(ab);
> > + }
> > return;
> > }
> > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > - "resp=%u fan_type=%u fan_info=%u",
> > - response, friar->hdr.type, friar->audit_rule);
> > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY);
> > + if (ab) {
> > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=",
> > + response, friar->hdr.type);
> > + audit_log_n_hex(ab, (char *)&friar->audit_rule,
> > + sizeof(friar->audit_rule));
>
> One thing to point out, the structure has a member audit_rule. It is
> probably better to call it rule_number. This is because it has nothing to
> do with any actual audit rule. It is a rule number meant to be recorded by
> the audit system.
>
> Also, that member is a __u32 type. Hex encoding that directly gives back a
> __u32 when decoded - which is a bit unexpected since everything else is
> strings. It would be better to convert the u32 to a base 10 string and then
> hex encode that. A buffer of 12 bytes should be sufficient.
Sure, these seem reasonable.
> Thanks,
> -Steve
>
> > + audit_log_end(ab);
> > +
> > + }
> > }
> > c -= friar->hdr.len;
> > ib += friar->hdr.len;
>
>
>
>
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
2022-08-19 17:17 ` Nick Desaulniers
(?)
@ 2022-08-19 21:45 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 21:45 UTC (permalink / raw)
To: Nick Desaulniers
Cc: kernel test robot, Linux-Audit Mailing List, LKML, linux-fsdevel,
llvm, kbuild-all, Paul Moore, Eric Paris, Steve Grubb, Jan Kara,
Amir Goldstein
On 2022-08-19 10:17, Nick Desaulniers wrote:
> On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > On 2022-08-10 22:28, kernel test robot wrote:
> > > Hi Richard,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on jack-fs/fsnotify]
> > > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > >
> > > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> > > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > > reproduce (this is a W=1 build):
> > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > > # save the config file
> > > mkdir build_dir && cp config build_dir/.config
> > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> >
> > Interesting. When I "fix" it, my compiler complains:
> >
> > fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
>
> The correct format specifier for size_t is %zu. This avoids issues
> between ILP32 vs LP64 targets.
Perfect, thanks!
> > > group, fd, response, info_buf, count);
> > > ^~~~~
> > > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > > printk(fmt, ##__VA_ARGS__); \
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > > _p_func(_fmt, ##__VA_ARGS__); \
> > > ~~~~ ^~~~~~~~~~~
> > > 1 warning generated.
> > >
> > >
> > > vim +325 fs/notify/fanotify/fanotify_user.c
> > >
> > > 312
> > > 313 static int process_access_response(struct fsnotify_group *group,
> > > 314 struct fanotify_response *response_struct,
> > > 315 const char __user *buf,
> > > 316 size_t count)
> > > 317 {
> > > 318 struct fanotify_perm_event *event;
> > > 319 int fd = response_struct->fd;
> > > 320 u32 response = response_struct->response;
> > > 321 struct fanotify_response_info_header info_hdr;
> > > 322 char *info_buf = NULL;
> > > 323
> > > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > > 325 group, fd, response, info_buf, count);
> > > 326 /*
> > > 327 * make sure the response is valid, if invalid we do nothing and either
> > > 328 * userspace can send a valid response or we will clean it up after the
> > > 329 * timeout
> > > 330 */
> > > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > > 332 return -EINVAL;
> > > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > > 334 case FAN_ALLOW:
> > > 335 case FAN_DENY:
> > > 336 break;
> > > 337 default:
> > > 338 return -EINVAL;
> > > 339 }
> > > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > > 341 return -EINVAL;
> > > 342 if (fd < 0)
> > > 343 return -EINVAL;
> > > 344 if (response & FAN_INFO) {
> > > 345 size_t c = count;
> > > 346 const char __user *ib = buf;
> > > 347
> > > 348 if (c <= 0)
> > > 349 return -EINVAL;
> > > 350 while (c >= sizeof(info_hdr)) {
> > > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > > 352 return -EFAULT;
> > > 353 if (info_hdr.pad != 0)
> > > 354 return -EINVAL;
> > > 355 if (c < info_hdr.len)
> > > 356 return -EINVAL;
> > > 357 switch (info_hdr.type) {
> > > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > > 359 break;
> > > 360 case FAN_RESPONSE_INFO_NONE:
> > > 361 default:
> > > 362 return -EINVAL;
> > > 363 }
> > > 364 c -= info_hdr.len;
> > > 365 ib += info_hdr.len;
> > > 366 }
> > > 367 if (c != 0)
> > > 368 return -EINVAL;
> > > 369 /* Simplistic check for now */
> > > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > > 371 return -EINVAL;
> > > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > > 373 GFP_KERNEL);
> > > 374 if (!info_buf)
> > > 375 return -ENOMEM;
> > > 376 if (copy_from_user(info_buf, buf, count))
> > > 377 return -EFAULT;
> > > 378 }
> > > 379 spin_lock(&group->notification_lock);
> > > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > > 381 fae.fse.list) {
> > > 382 if (event->fd != fd)
> > > 383 continue;
> > > 384
> > > 385 list_del_init(&event->fae.fse.list);
> > > 386 /* finish_permission_event() eats info_buf */
> > > 387 finish_permission_event(group, event, response_struct,
> > > 388 count, info_buf);
> > > 389 wake_up(&group->fanotify_data.access_waitq);
> > > 390 return 0;
> > > 391 }
> > > 392 spin_unlock(&group->notification_lock);
> > > 393
> > > 394 return -ENOENT;
> > > 395 }
> > > 396
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://01.org/lkp
> > >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@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
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 21:45 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 21:45 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Amir Goldstein, kbuild-all, kernel test robot, Jan Kara, llvm,
LKML, Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On 2022-08-19 10:17, Nick Desaulniers wrote:
> On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > On 2022-08-10 22:28, kernel test robot wrote:
> > > Hi Richard,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on jack-fs/fsnotify]
> > > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > >
> > > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp@intel.com/config)
> > > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > > reproduce (this is a W=1 build):
> > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > > # save the config file
> > > mkdir build_dir && cp config build_dir/.config
> > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> >
> > Interesting. When I "fix" it, my compiler complains:
> >
> > fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
>
> The correct format specifier for size_t is %zu. This avoids issues
> between ILP32 vs LP64 targets.
Perfect, thanks!
> > > group, fd, response, info_buf, count);
> > > ^~~~~
> > > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > > printk(fmt, ##__VA_ARGS__); \
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > > _p_func(_fmt, ##__VA_ARGS__); \
> > > ~~~~ ^~~~~~~~~~~
> > > 1 warning generated.
> > >
> > >
> > > vim +325 fs/notify/fanotify/fanotify_user.c
> > >
> > > 312
> > > 313 static int process_access_response(struct fsnotify_group *group,
> > > 314 struct fanotify_response *response_struct,
> > > 315 const char __user *buf,
> > > 316 size_t count)
> > > 317 {
> > > 318 struct fanotify_perm_event *event;
> > > 319 int fd = response_struct->fd;
> > > 320 u32 response = response_struct->response;
> > > 321 struct fanotify_response_info_header info_hdr;
> > > 322 char *info_buf = NULL;
> > > 323
> > > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > > 325 group, fd, response, info_buf, count);
> > > 326 /*
> > > 327 * make sure the response is valid, if invalid we do nothing and either
> > > 328 * userspace can send a valid response or we will clean it up after the
> > > 329 * timeout
> > > 330 */
> > > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > > 332 return -EINVAL;
> > > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > > 334 case FAN_ALLOW:
> > > 335 case FAN_DENY:
> > > 336 break;
> > > 337 default:
> > > 338 return -EINVAL;
> > > 339 }
> > > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > > 341 return -EINVAL;
> > > 342 if (fd < 0)
> > > 343 return -EINVAL;
> > > 344 if (response & FAN_INFO) {
> > > 345 size_t c = count;
> > > 346 const char __user *ib = buf;
> > > 347
> > > 348 if (c <= 0)
> > > 349 return -EINVAL;
> > > 350 while (c >= sizeof(info_hdr)) {
> > > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > > 352 return -EFAULT;
> > > 353 if (info_hdr.pad != 0)
> > > 354 return -EINVAL;
> > > 355 if (c < info_hdr.len)
> > > 356 return -EINVAL;
> > > 357 switch (info_hdr.type) {
> > > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > > 359 break;
> > > 360 case FAN_RESPONSE_INFO_NONE:
> > > 361 default:
> > > 362 return -EINVAL;
> > > 363 }
> > > 364 c -= info_hdr.len;
> > > 365 ib += info_hdr.len;
> > > 366 }
> > > 367 if (c != 0)
> > > 368 return -EINVAL;
> > > 369 /* Simplistic check for now */
> > > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > > 371 return -EINVAL;
> > > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > > 373 GFP_KERNEL);
> > > 374 if (!info_buf)
> > > 375 return -ENOMEM;
> > > 376 if (copy_from_user(info_buf, buf, count))
> > > 377 return -EFAULT;
> > > 378 }
> > > 379 spin_lock(&group->notification_lock);
> > > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > > 381 fae.fse.list) {
> > > 382 if (event->fd != fd)
> > > 383 continue;
> > > 384
> > > 385 list_del_init(&event->fae.fse.list);
> > > 386 /* finish_permission_event() eats info_buf */
> > > 387 finish_permission_event(group, event, response_struct,
> > > 388 count, info_buf);
> > > 389 wake_up(&group->fanotify_data.access_waitq);
> > > 390 return 0;
> > > 391 }
> > > 392 spin_unlock(&group->notification_lock);
> > > 393
> > > 394 return -ENOENT;
> > > 395 }
> > > 396
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://01.org/lkp
> > >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@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
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 2/4] fanotify: define struct members to hold response decision context
@ 2022-08-19 21:45 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-19 21:45 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 9585 bytes --]
On 2022-08-19 10:17, Nick Desaulniers wrote:
> On Fri, Aug 19, 2022 at 9:25 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > On 2022-08-10 22:28, kernel test robot wrote:
> > > Hi Richard,
> > >
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test WARNING on jack-fs/fsnotify]
> > > [also build test WARNING on pcmoore-audit/next linus/master v5.19 next-20220810]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > >
> > > url: https://github.com/intel-lab-lkp/linux/commits/Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > > config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220810/202208102231.qSUdYAdb-lkp(a)intel.com/config)
> > > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
> > > reproduce (this is a W=1 build):
> > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # https://github.com/intel-lab-lkp/linux/commit/a943676abc023c094f05b45f4d61936c567507a2
> > > git remote add linux-review https://github.com/intel-lab-lkp/linux
> > > git fetch --no-tags linux-review Richard-Guy-Briggs/fanotify-Allow-user-space-to-pass-back-additional-audit-info/20220810-012825
> > > git checkout a943676abc023c094f05b45f4d61936c567507a2
> > > # save the config file
> > > mkdir build_dir && cp config build_dir/.config
> > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash fs/notify/fanotify/
> > >
> > > If you fix the issue, kindly add following tag where applicable
> > > Reported-by: kernel test robot <lkp@intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> fs/notify/fanotify/fanotify_user.c:325:35: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat]
> >
> > Interesting. When I "fix" it, my compiler complains:
> >
> > fs/notify/fanotify/fanotify_user.c:324:11: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 8 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
>
> The correct format specifier for size_t is %zu. This avoids issues
> between ILP32 vs LP64 targets.
Perfect, thanks!
> > > group, fd, response, info_buf, count);
> > > ^~~~~
> > > include/linux/printk.h:594:38: note: expanded from macro 'pr_debug'
> > > no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:131:17: note: expanded from macro 'no_printk'
> > > printk(fmt, ##__VA_ARGS__); \
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:464:60: note: expanded from macro 'printk'
> > > #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
> > > ~~~ ^~~~~~~~~~~
> > > include/linux/printk.h:436:19: note: expanded from macro 'printk_index_wrap'
> > > _p_func(_fmt, ##__VA_ARGS__); \
> > > ~~~~ ^~~~~~~~~~~
> > > 1 warning generated.
> > >
> > >
> > > vim +325 fs/notify/fanotify/fanotify_user.c
> > >
> > > 312
> > > 313 static int process_access_response(struct fsnotify_group *group,
> > > 314 struct fanotify_response *response_struct,
> > > 315 const char __user *buf,
> > > 316 size_t count)
> > > 317 {
> > > 318 struct fanotify_perm_event *event;
> > > 319 int fd = response_struct->fd;
> > > 320 u32 response = response_struct->response;
> > > 321 struct fanotify_response_info_header info_hdr;
> > > 322 char *info_buf = NULL;
> > > 323
> > > 324 pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__,
> > > > 325 group, fd, response, info_buf, count);
> > > 326 /*
> > > 327 * make sure the response is valid, if invalid we do nothing and either
> > > 328 * userspace can send a valid response or we will clean it up after the
> > > 329 * timeout
> > > 330 */
> > > 331 if (response & ~FANOTIFY_RESPONSE_VALID_MASK)
> > > 332 return -EINVAL;
> > > 333 switch (response & FANOTIFY_RESPONSE_ACCESS) {
> > > 334 case FAN_ALLOW:
> > > 335 case FAN_DENY:
> > > 336 break;
> > > 337 default:
> > > 338 return -EINVAL;
> > > 339 }
> > > 340 if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT))
> > > 341 return -EINVAL;
> > > 342 if (fd < 0)
> > > 343 return -EINVAL;
> > > 344 if (response & FAN_INFO) {
> > > 345 size_t c = count;
> > > 346 const char __user *ib = buf;
> > > 347
> > > 348 if (c <= 0)
> > > 349 return -EINVAL;
> > > 350 while (c >= sizeof(info_hdr)) {
> > > 351 if (copy_from_user(&info_hdr, ib, sizeof(info_hdr)))
> > > 352 return -EFAULT;
> > > 353 if (info_hdr.pad != 0)
> > > 354 return -EINVAL;
> > > 355 if (c < info_hdr.len)
> > > 356 return -EINVAL;
> > > 357 switch (info_hdr.type) {
> > > 358 case FAN_RESPONSE_INFO_AUDIT_RULE:
> > > 359 break;
> > > 360 case FAN_RESPONSE_INFO_NONE:
> > > 361 default:
> > > 362 return -EINVAL;
> > > 363 }
> > > 364 c -= info_hdr.len;
> > > 365 ib += info_hdr.len;
> > > 366 }
> > > 367 if (c != 0)
> > > 368 return -EINVAL;
> > > 369 /* Simplistic check for now */
> > > 370 if (count != sizeof(struct fanotify_response_info_audit_rule))
> > > 371 return -EINVAL;
> > > 372 info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule),
> > > 373 GFP_KERNEL);
> > > 374 if (!info_buf)
> > > 375 return -ENOMEM;
> > > 376 if (copy_from_user(info_buf, buf, count))
> > > 377 return -EFAULT;
> > > 378 }
> > > 379 spin_lock(&group->notification_lock);
> > > 380 list_for_each_entry(event, &group->fanotify_data.access_list,
> > > 381 fae.fse.list) {
> > > 382 if (event->fd != fd)
> > > 383 continue;
> > > 384
> > > 385 list_del_init(&event->fae.fse.list);
> > > 386 /* finish_permission_event() eats info_buf */
> > > 387 finish_permission_event(group, event, response_struct,
> > > 388 count, info_buf);
> > > 389 wake_up(&group->fanotify_data.access_waitq);
> > > 390 return 0;
> > > 391 }
> > > 392 spin_unlock(&group->notification_lock);
> > > 393
> > > 394 return -ENOENT;
> > > 395 }
> > > 396
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://01.org/lkp
> > >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@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
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-16 0:22 ` Paul Moore
@ 2022-08-31 21:07 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-31 21:07 UTC (permalink / raw)
To: Steve Grubb, Paul Moore
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Jan Kara, Amir Goldstein
On 2022-08-15 20:22, Paul Moore wrote:
> On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > This patch passes the full value so that the audit function can use all
> > of it. The audit function was updated to log the additional information in
> > the AUDIT_FANOTIFY record. The following is an example of the new record
> > format:
> >
> > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > fs/notify/fanotify/fanotify.c | 3 ++-
> > include/linux/audit.h | 9 +++++----
> > kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
> > 3 files changed, 35 insertions(+), 8 deletions(-)
>
> You've hopefully already seen the kernel test robot build warning, so
> I won't bring that up again, but a few comments below ...
Yes, dealt with...
...
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 433418d73584..f000fec52360 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -64,6 +64,7 @@
> > #include <uapi/linux/limits.h>
> > #include <uapi/linux/netfilter/nf_tables.h>
> > #include <uapi/linux/openat2.h> // struct open_how
> > +#include <uapi/linux/fanotify.h>
> >
> > #include "audit.h"
> >
> > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > context->type = AUDIT_KERN_MODULE;
> > }
> >
> > -void __audit_fanotify(u32 response)
> > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > {
> > - audit_log(audit_context(), GFP_KERNEL,
> > - AUDIT_FANOTIFY, "resp=%u", response);
> > + struct fanotify_response_info_audit_rule *friar;
> > + size_t c = len;
> > + char *ib = buf;
> > +
> > + if (!(len && buf)) {
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=0 fan_info=?", response);
> > + return;
> > + }
> > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > + friar = (struct fanotify_response_info_audit_rule *)buf;
>
> Since the only use of this at the moment is the
> fanotify_response_info_rule, why not pass the
> fanotify_response_info_rule struct directly into this function? We
> can always change it if we need to in the future without affecting
> userspace, and it would simplify the code.
Steve, would it make any sense for there to be more than one
FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
than one rule that contributes to a notify reason? If not, would it be
reasonable to return -EINVAL if there is more than one?
> > + switch (friar->hdr.type) {
> > + case FAN_RESPONSE_INFO_AUDIT_RULE:
> > + if (friar->hdr.len < sizeof(*friar)) {
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=(incomplete)",
> > + response, friar->hdr.type);
> > + return;
> > + }
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=%u",
> > + response, friar->hdr.type, friar->audit_rule);
> > + }
> > + c -= friar->hdr.len;
> > + ib += friar->hdr.len;
> > + }
> > }
> >
> > void __audit_tk_injoffset(struct timespec64 offset)
>
> paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-08-31 21:07 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-31 21:07 UTC (permalink / raw)
To: Steve Grubb, Paul Moore
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-08-15 20:22, Paul Moore wrote:
> On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> >
> > This patch passes the full value so that the audit function can use all
> > of it. The audit function was updated to log the additional information in
> > the AUDIT_FANOTIFY record. The following is an example of the new record
> > format:
> >
> > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17
> >
> > Suggested-by: Steve Grubb <sgrubb@redhat.com>
> > Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > ---
> > fs/notify/fanotify/fanotify.c | 3 ++-
> > include/linux/audit.h | 9 +++++----
> > kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
> > 3 files changed, 35 insertions(+), 8 deletions(-)
>
> You've hopefully already seen the kernel test robot build warning, so
> I won't bring that up again, but a few comments below ...
Yes, dealt with...
...
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 433418d73584..f000fec52360 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -64,6 +64,7 @@
> > #include <uapi/linux/limits.h>
> > #include <uapi/linux/netfilter/nf_tables.h>
> > #include <uapi/linux/openat2.h> // struct open_how
> > +#include <uapi/linux/fanotify.h>
> >
> > #include "audit.h"
> >
> > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > context->type = AUDIT_KERN_MODULE;
> > }
> >
> > -void __audit_fanotify(u32 response)
> > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > {
> > - audit_log(audit_context(), GFP_KERNEL,
> > - AUDIT_FANOTIFY, "resp=%u", response);
> > + struct fanotify_response_info_audit_rule *friar;
> > + size_t c = len;
> > + char *ib = buf;
> > +
> > + if (!(len && buf)) {
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=0 fan_info=?", response);
> > + return;
> > + }
> > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > + friar = (struct fanotify_response_info_audit_rule *)buf;
>
> Since the only use of this at the moment is the
> fanotify_response_info_rule, why not pass the
> fanotify_response_info_rule struct directly into this function? We
> can always change it if we need to in the future without affecting
> userspace, and it would simplify the code.
Steve, would it make any sense for there to be more than one
FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
than one rule that contributes to a notify reason? If not, would it be
reasonable to return -EINVAL if there is more than one?
> > + switch (friar->hdr.type) {
> > + case FAN_RESPONSE_INFO_AUDIT_RULE:
> > + if (friar->hdr.len < sizeof(*friar)) {
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=(incomplete)",
> > + response, friar->hdr.type);
> > + return;
> > + }
> > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > + "resp=%u fan_type=%u fan_info=%u",
> > + response, friar->hdr.type, friar->audit_rule);
> > + }
> > + c -= friar->hdr.len;
> > + ib += friar->hdr.len;
> > + }
> > }
> >
> > void __audit_tk_injoffset(struct timespec64 offset)
>
> paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-31 21:07 ` Richard Guy Briggs
@ 2022-08-31 21:25 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-31 21:25 UTC (permalink / raw)
To: Paul Moore, Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Jan Kara, Amir Goldstein
On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 433418d73584..f000fec52360 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -64,6 +64,7 @@
> > > #include <uapi/linux/limits.h>
> > > #include <uapi/linux/netfilter/nf_tables.h>
> > > #include <uapi/linux/openat2.h> // struct open_how
> > > +#include <uapi/linux/fanotify.h>
> > >
> > > #include "audit.h"
> > >
> > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > context->type = AUDIT_KERN_MODULE;
> > > }
> > >
> > > -void __audit_fanotify(u32 response)
> > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > {
> > > - audit_log(audit_context(), GFP_KERNEL,
> > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > + struct fanotify_response_info_audit_rule *friar;
> > > + size_t c = len;
> > > + char *ib = buf;
> > > +
> > > + if (!(len && buf)) {
> > > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > > + "resp=%u fan_type=0 fan_info=?", response);
> > > + return;
> > > + }
> > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > + friar = (struct fanotify_response_info_audit_rule
> > > *)buf;
> >
> > Since the only use of this at the moment is the
> > fanotify_response_info_rule, why not pass the
> > fanotify_response_info_rule struct directly into this function? We
> > can always change it if we need to in the future without affecting
> > userspace, and it would simplify the code.
>
> Steve, would it make any sense for there to be more than one
> FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> than one rule that contributes to a notify reason? If not, would it be
> reasonable to return -EINVAL if there is more than one?
I don't see a reason for sending more than one header. What is more probable
is the need to send additional data in that header. I was thinking of maybe
bit mapping it in the rule number. But I'd suggest padding the struct just in
case it needs expanding some day.
-Steev
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-08-31 21:25 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-31 21:25 UTC (permalink / raw)
To: Paul Moore, Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 433418d73584..f000fec52360 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -64,6 +64,7 @@
> > > #include <uapi/linux/limits.h>
> > > #include <uapi/linux/netfilter/nf_tables.h>
> > > #include <uapi/linux/openat2.h> // struct open_how
> > > +#include <uapi/linux/fanotify.h>
> > >
> > > #include "audit.h"
> > >
> > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > context->type = AUDIT_KERN_MODULE;
> > > }
> > >
> > > -void __audit_fanotify(u32 response)
> > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > {
> > > - audit_log(audit_context(), GFP_KERNEL,
> > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > + struct fanotify_response_info_audit_rule *friar;
> > > + size_t c = len;
> > > + char *ib = buf;
> > > +
> > > + if (!(len && buf)) {
> > > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > > + "resp=%u fan_type=0 fan_info=?", response);
> > > + return;
> > > + }
> > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > + friar = (struct fanotify_response_info_audit_rule
> > > *)buf;
> >
> > Since the only use of this at the moment is the
> > fanotify_response_info_rule, why not pass the
> > fanotify_response_info_rule struct directly into this function? We
> > can always change it if we need to in the future without affecting
> > userspace, and it would simplify the code.
>
> Steve, would it make any sense for there to be more than one
> FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> than one rule that contributes to a notify reason? If not, would it be
> reasonable to return -EINVAL if there is more than one?
I don't see a reason for sending more than one header. What is more probable
is the need to send additional data in that header. I was thinking of maybe
bit mapping it in the rule number. But I'd suggest padding the struct just in
case it needs expanding some day.
-Steev
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-31 21:25 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-08-31 22:19 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-31 22:19 UTC (permalink / raw)
To: Steve Grubb
Cc: Paul Moore, Linux-Audit Mailing List, LKML, linux-fsdevel,
Eric Paris, Jan Kara, Amir Goldstein
On 2022-08-31 17:25, Steve Grubb wrote:
> On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > index 433418d73584..f000fec52360 100644
> > > > --- a/kernel/auditsc.c
> > > > +++ b/kernel/auditsc.c
> > > > @@ -64,6 +64,7 @@
> > > > #include <uapi/linux/limits.h>
> > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > +#include <uapi/linux/fanotify.h>
> > > >
> > > > #include "audit.h"
> > > >
> > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > context->type = AUDIT_KERN_MODULE;
> > > > }
> > > >
> > > > -void __audit_fanotify(u32 response)
> > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > {
> > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > + struct fanotify_response_info_audit_rule *friar;
> > > > + size_t c = len;
> > > > + char *ib = buf;
> > > > +
> > > > + if (!(len && buf)) {
> > > > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > > > + "resp=%u fan_type=0 fan_info=?", response);
> > > > + return;
> > > > + }
> > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > + friar = (struct fanotify_response_info_audit_rule
> > > > *)buf;
> > >
> > > Since the only use of this at the moment is the
> > > fanotify_response_info_rule, why not pass the
> > > fanotify_response_info_rule struct directly into this function? We
> > > can always change it if we need to in the future without affecting
> > > userspace, and it would simplify the code.
> >
> > Steve, would it make any sense for there to be more than one
> > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > than one rule that contributes to a notify reason? If not, would it be
> > reasonable to return -EINVAL if there is more than one?
>
> I don't see a reason for sending more than one header. What is more probable
> is the need to send additional data in that header. I was thinking of maybe
> bit mapping it in the rule number. But I'd suggest padding the struct just in
> case it needs expanding some day.
This doesn't exactly answer my question about multiple rules
contributing to one decision.
The need for more as yet undefined information sounds like a good reason
to define a new header if that happens.
At this point, is it reasonable to throw an error if more than one RULE
header appears in a message? The way I had coded this last patchset was
to allow for more than one RULE header and each one would get its own
record in the event.
How many rules total are likely to exist?
> -Steev
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-08-31 22:19 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-08-31 22:19 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-08-31 17:25, Steve Grubb wrote:
> On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > index 433418d73584..f000fec52360 100644
> > > > --- a/kernel/auditsc.c
> > > > +++ b/kernel/auditsc.c
> > > > @@ -64,6 +64,7 @@
> > > > #include <uapi/linux/limits.h>
> > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > +#include <uapi/linux/fanotify.h>
> > > >
> > > > #include "audit.h"
> > > >
> > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > context->type = AUDIT_KERN_MODULE;
> > > > }
> > > >
> > > > -void __audit_fanotify(u32 response)
> > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > {
> > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > + struct fanotify_response_info_audit_rule *friar;
> > > > + size_t c = len;
> > > > + char *ib = buf;
> > > > +
> > > > + if (!(len && buf)) {
> > > > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> > > > + "resp=%u fan_type=0 fan_info=?", response);
> > > > + return;
> > > > + }
> > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > + friar = (struct fanotify_response_info_audit_rule
> > > > *)buf;
> > >
> > > Since the only use of this at the moment is the
> > > fanotify_response_info_rule, why not pass the
> > > fanotify_response_info_rule struct directly into this function? We
> > > can always change it if we need to in the future without affecting
> > > userspace, and it would simplify the code.
> >
> > Steve, would it make any sense for there to be more than one
> > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > than one rule that contributes to a notify reason? If not, would it be
> > reasonable to return -EINVAL if there is more than one?
>
> I don't see a reason for sending more than one header. What is more probable
> is the need to send additional data in that header. I was thinking of maybe
> bit mapping it in the rule number. But I'd suggest padding the struct just in
> case it needs expanding some day.
This doesn't exactly answer my question about multiple rules
contributing to one decision.
The need for more as yet undefined information sounds like a good reason
to define a new header if that happens.
At this point, is it reasonable to throw an error if more than one RULE
header appears in a message? The way I had coded this last patchset was
to allow for more than one RULE header and each one would get its own
record in the event.
How many rules total are likely to exist?
> -Steev
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-31 22:19 ` Richard Guy Briggs
@ 2022-08-31 23:55 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-31 23:55 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Paul Moore, Linux-Audit Mailing List, LKML, linux-fsdevel,
Eric Paris, Jan Kara, Amir Goldstein
On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> On 2022-08-31 17:25, Steve Grubb wrote:
> > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > index 433418d73584..f000fec52360 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -64,6 +64,7 @@
> > > > > #include <uapi/linux/limits.h>
> > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > +#include <uapi/linux/fanotify.h>
> > > > >
> > > > > #include "audit.h"
> > > > >
> > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > context->type = AUDIT_KERN_MODULE;
> > > > > }
> > > > >
> > > > > -void __audit_fanotify(u32 response)
> > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > {
> > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > + size_t c = len;
> > > > > + char *ib = buf;
> > > > > +
> > > > > + if (!(len && buf)) {
> > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > AUDIT_FANOTIFY,
> > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > response);
> > > > > + return;
> > > > > + }
> > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > *)buf;
> > > >
> > > > Since the only use of this at the moment is the
> > > > fanotify_response_info_rule, why not pass the
> > > > fanotify_response_info_rule struct directly into this function? We
> > > > can always change it if we need to in the future without affecting
> > > > userspace, and it would simplify the code.
> > >
> > > Steve, would it make any sense for there to be more than one
> > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > than one rule that contributes to a notify reason? If not, would it be
> > > reasonable to return -EINVAL if there is more than one?
> >
> > I don't see a reason for sending more than one header. What is more
> > probable is the need to send additional data in that header. I was
> > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > padding the struct just in case it needs expanding some day.
>
> This doesn't exactly answer my question about multiple rules
> contributing to one decision.
I don't forsee that.
> The need for more as yet undefined information sounds like a good reason
> to define a new header if that happens.
It's much better to pad the struct so that the size doesn't change.
> At this point, is it reasonable to throw an error if more than one RULE
> header appears in a message?
It is a write syscall. I'd silently discard everything else and document that
in the man pages. But the fanotify maintainers should really weigh in on
this.
> The way I had coded this last patchset was to allow for more than one RULE
> header and each one would get its own record in the event.
I do not forsee a need for this.
> How many rules total are likely to exist?
Could be a thousand. But I already know some missing information we'd like to
return to user space in an audit event, so the bit mapping on the rule number
might happen. I'd suggest padding one u32 for future use.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-08-31 23:55 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-08-31 23:55 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> On 2022-08-31 17:25, Steve Grubb wrote:
> > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > index 433418d73584..f000fec52360 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -64,6 +64,7 @@
> > > > > #include <uapi/linux/limits.h>
> > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > +#include <uapi/linux/fanotify.h>
> > > > >
> > > > > #include "audit.h"
> > > > >
> > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > context->type = AUDIT_KERN_MODULE;
> > > > > }
> > > > >
> > > > > -void __audit_fanotify(u32 response)
> > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > {
> > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > + size_t c = len;
> > > > > + char *ib = buf;
> > > > > +
> > > > > + if (!(len && buf)) {
> > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > AUDIT_FANOTIFY,
> > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > response);
> > > > > + return;
> > > > > + }
> > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > *)buf;
> > > >
> > > > Since the only use of this at the moment is the
> > > > fanotify_response_info_rule, why not pass the
> > > > fanotify_response_info_rule struct directly into this function? We
> > > > can always change it if we need to in the future without affecting
> > > > userspace, and it would simplify the code.
> > >
> > > Steve, would it make any sense for there to be more than one
> > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > than one rule that contributes to a notify reason? If not, would it be
> > > reasonable to return -EINVAL if there is more than one?
> >
> > I don't see a reason for sending more than one header. What is more
> > probable is the need to send additional data in that header. I was
> > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > padding the struct just in case it needs expanding some day.
>
> This doesn't exactly answer my question about multiple rules
> contributing to one decision.
I don't forsee that.
> The need for more as yet undefined information sounds like a good reason
> to define a new header if that happens.
It's much better to pad the struct so that the size doesn't change.
> At this point, is it reasonable to throw an error if more than one RULE
> header appears in a message?
It is a write syscall. I'd silently discard everything else and document that
in the man pages. But the fanotify maintainers should really weigh in on
this.
> The way I had coded this last patchset was to allow for more than one RULE
> header and each one would get its own record in the event.
I do not forsee a need for this.
> How many rules total are likely to exist?
Could be a thousand. But I already know some missing information we'd like to
return to user space in an audit event, so the bit mapping on the rule number
might happen. I'd suggest padding one u32 for future use.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-08-31 23:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-01 1:47 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-01 1:47 UTC (permalink / raw)
To: Steve Grubb
Cc: Richard Guy Briggs, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Jan Kara, Amir Goldstein
On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > On 2022-08-31 17:25, Steve Grubb wrote:
> > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > index 433418d73584..f000fec52360 100644
> > > > > > --- a/kernel/auditsc.c
> > > > > > +++ b/kernel/auditsc.c
> > > > > > @@ -64,6 +64,7 @@
> > > > > > #include <uapi/linux/limits.h>
> > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > +#include <uapi/linux/fanotify.h>
> > > > > >
> > > > > > #include "audit.h"
> > > > > >
> > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > }
> > > > > >
> > > > > > -void __audit_fanotify(u32 response)
> > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > {
> > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > + size_t c = len;
> > > > > > + char *ib = buf;
> > > > > > +
> > > > > > + if (!(len && buf)) {
> > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > AUDIT_FANOTIFY,
> > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > response);
> > > > > > + return;
> > > > > > + }
> > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > *)buf;
> > > > >
> > > > > Since the only use of this at the moment is the
> > > > > fanotify_response_info_rule, why not pass the
> > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > can always change it if we need to in the future without affecting
> > > > > userspace, and it would simplify the code.
> > > >
> > > > Steve, would it make any sense for there to be more than one
> > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > than one rule that contributes to a notify reason? If not, would it be
> > > > reasonable to return -EINVAL if there is more than one?
> > >
> > > I don't see a reason for sending more than one header. What is more
> > > probable is the need to send additional data in that header. I was
> > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > padding the struct just in case it needs expanding some day.
> >
> > This doesn't exactly answer my question about multiple rules
> > contributing to one decision.
>
> I don't forsee that.
>
> > The need for more as yet undefined information sounds like a good reason
> > to define a new header if that happens.
>
> It's much better to pad the struct so that the size doesn't change.
>
> > At this point, is it reasonable to throw an error if more than one RULE
> > header appears in a message?
>
> It is a write syscall. I'd silently discard everything else and document that
> in the man pages. But the fanotify maintainers should really weigh in on
> this.
>
> > The way I had coded this last patchset was to allow for more than one RULE
> > header and each one would get its own record in the event.
>
> I do not forsee a need for this.
>
> > How many rules total are likely to exist?
>
> Could be a thousand. But I already know some missing information we'd like to
> return to user space in an audit event, so the bit mapping on the rule number
> might happen. I'd suggest padding one u32 for future use.
A better way to handle an expansion like that would be to have a
length/version field at the top of the struct that could be used to
determine the size and layout of the struct.
However, to be clear, my original suggestion of passing the
fanotify_response_info_rule struct internally didn't require any
additional future proofing as it is an internal implementation detail
and not something that is exposed to userspace; the function arguments
could be changed in the future and not break userspace. I'm not quite
sure how we ended up on this topic ...
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-01 1:47 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-01 1:47 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > On 2022-08-31 17:25, Steve Grubb wrote:
> > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > index 433418d73584..f000fec52360 100644
> > > > > > --- a/kernel/auditsc.c
> > > > > > +++ b/kernel/auditsc.c
> > > > > > @@ -64,6 +64,7 @@
> > > > > > #include <uapi/linux/limits.h>
> > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > +#include <uapi/linux/fanotify.h>
> > > > > >
> > > > > > #include "audit.h"
> > > > > >
> > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > }
> > > > > >
> > > > > > -void __audit_fanotify(u32 response)
> > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > {
> > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > + size_t c = len;
> > > > > > + char *ib = buf;
> > > > > > +
> > > > > > + if (!(len && buf)) {
> > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > AUDIT_FANOTIFY,
> > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > response);
> > > > > > + return;
> > > > > > + }
> > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > *)buf;
> > > > >
> > > > > Since the only use of this at the moment is the
> > > > > fanotify_response_info_rule, why not pass the
> > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > can always change it if we need to in the future without affecting
> > > > > userspace, and it would simplify the code.
> > > >
> > > > Steve, would it make any sense for there to be more than one
> > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > than one rule that contributes to a notify reason? If not, would it be
> > > > reasonable to return -EINVAL if there is more than one?
> > >
> > > I don't see a reason for sending more than one header. What is more
> > > probable is the need to send additional data in that header. I was
> > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > padding the struct just in case it needs expanding some day.
> >
> > This doesn't exactly answer my question about multiple rules
> > contributing to one decision.
>
> I don't forsee that.
>
> > The need for more as yet undefined information sounds like a good reason
> > to define a new header if that happens.
>
> It's much better to pad the struct so that the size doesn't change.
>
> > At this point, is it reasonable to throw an error if more than one RULE
> > header appears in a message?
>
> It is a write syscall. I'd silently discard everything else and document that
> in the man pages. But the fanotify maintainers should really weigh in on
> this.
>
> > The way I had coded this last patchset was to allow for more than one RULE
> > header and each one would get its own record in the event.
>
> I do not forsee a need for this.
>
> > How many rules total are likely to exist?
>
> Could be a thousand. But I already know some missing information we'd like to
> return to user space in an audit event, so the bit mapping on the rule number
> might happen. I'd suggest padding one u32 for future use.
A better way to handle an expansion like that would be to have a
length/version field at the top of the struct that could be used to
determine the size and layout of the struct.
However, to be clear, my original suggestion of passing the
fanotify_response_info_rule struct internally didn't require any
additional future proofing as it is an internal implementation detail
and not something that is exposed to userspace; the function arguments
could be changed in the future and not break userspace. I'm not quite
sure how we ended up on this topic ...
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-01 1:47 ` Paul Moore
@ 2022-09-01 7:51 ` Jan Kara
-1 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-09-01 7:51 UTC (permalink / raw)
To: Paul Moore
Cc: Steve Grubb, Richard Guy Briggs, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Jan Kara, Amir Goldstein
On Wed 31-08-22 21:47:09, Paul Moore wrote:
> On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > --- a/kernel/auditsc.c
> > > > > > > +++ b/kernel/auditsc.c
> > > > > > > @@ -64,6 +64,7 @@
> > > > > > > #include <uapi/linux/limits.h>
> > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > >
> > > > > > > #include "audit.h"
> > > > > > >
> > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > }
> > > > > > >
> > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > {
> > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > + size_t c = len;
> > > > > > > + char *ib = buf;
> > > > > > > +
> > > > > > > + if (!(len && buf)) {
> > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > AUDIT_FANOTIFY,
> > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > response);
> > > > > > > + return;
> > > > > > > + }
> > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > *)buf;
> > > > > >
> > > > > > Since the only use of this at the moment is the
> > > > > > fanotify_response_info_rule, why not pass the
> > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > can always change it if we need to in the future without affecting
> > > > > > userspace, and it would simplify the code.
> > > > >
> > > > > Steve, would it make any sense for there to be more than one
> > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > reasonable to return -EINVAL if there is more than one?
> > > >
> > > > I don't see a reason for sending more than one header. What is more
> > > > probable is the need to send additional data in that header. I was
> > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > padding the struct just in case it needs expanding some day.
> > >
> > > This doesn't exactly answer my question about multiple rules
> > > contributing to one decision.
> >
> > I don't forsee that.
> >
> > > The need for more as yet undefined information sounds like a good reason
> > > to define a new header if that happens.
> >
> > It's much better to pad the struct so that the size doesn't change.
> >
> > > At this point, is it reasonable to throw an error if more than one RULE
> > > header appears in a message?
> >
> > It is a write syscall. I'd silently discard everything else and document that
> > in the man pages. But the fanotify maintainers should really weigh in on
> > this.
> >
> > > The way I had coded this last patchset was to allow for more than one RULE
> > > header and each one would get its own record in the event.
> >
> > I do not forsee a need for this.
> >
> > > How many rules total are likely to exist?
> >
> > Could be a thousand. But I already know some missing information we'd like to
> > return to user space in an audit event, so the bit mapping on the rule number
> > might happen. I'd suggest padding one u32 for future use.
>
> A better way to handle an expansion like that would be to have a
> length/version field at the top of the struct that could be used to
> determine the size and layout of the struct.
We already do have the 'type' and 'len' fields in
struct fanotify_response_info_header. So if audit needs to pass more
information, we can define a new 'type' and either make it replace the
current struct fanotify_response_info_audit_rule or make it expand the
information in it. At least this is how we handle similar situation when
fanotify wants to report some new bits of information to userspace.
That being said if audit wants to have u32 pad in its struct
fanotify_response_info_audit_rule for future "optional" expansion I'm not
strictly opposed to that but I don't think it is a good idea. It is tricky
to safely start using the new field. Audit subsystem can define that the
kernel currently just ignores the field. And new kernel could start using
the passed information in the additional field but that is somewhat risky
because until that moment userspace can be passing random garbage in that
unused field and thus break when running on new kernel that tries to make
sense of it. Sure you can say it is broken userspace that does not properly
initialize the padding field but history has shown us multiple times that
events like these do happen and the breakage was unpleasant enough for
users that the kernel just had to revert back to ignoring the field.
Alternatively the kernel could bail with error if the new field is non-zero
but that would block new userspace using that field from running on old
kernel. But presumably the new userspace could be handling the error and
writing another response with new field zeroed out. That would be a safe
option although not very different from defining a new response type.
Ultimately I guess I'll leave it upto audit subsystem what it wants to have
in its struct fanotify_response_info_audit_rule because for fanotify
subsystem, it is just an opaque blob it is passing.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-01 7:51 ` Jan Kara
0 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-09-01 7:51 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Wed 31-08-22 21:47:09, Paul Moore wrote:
> On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > --- a/kernel/auditsc.c
> > > > > > > +++ b/kernel/auditsc.c
> > > > > > > @@ -64,6 +64,7 @@
> > > > > > > #include <uapi/linux/limits.h>
> > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > >
> > > > > > > #include "audit.h"
> > > > > > >
> > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > }
> > > > > > >
> > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > {
> > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > + size_t c = len;
> > > > > > > + char *ib = buf;
> > > > > > > +
> > > > > > > + if (!(len && buf)) {
> > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > AUDIT_FANOTIFY,
> > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > response);
> > > > > > > + return;
> > > > > > > + }
> > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > *)buf;
> > > > > >
> > > > > > Since the only use of this at the moment is the
> > > > > > fanotify_response_info_rule, why not pass the
> > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > can always change it if we need to in the future without affecting
> > > > > > userspace, and it would simplify the code.
> > > > >
> > > > > Steve, would it make any sense for there to be more than one
> > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > reasonable to return -EINVAL if there is more than one?
> > > >
> > > > I don't see a reason for sending more than one header. What is more
> > > > probable is the need to send additional data in that header. I was
> > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > padding the struct just in case it needs expanding some day.
> > >
> > > This doesn't exactly answer my question about multiple rules
> > > contributing to one decision.
> >
> > I don't forsee that.
> >
> > > The need for more as yet undefined information sounds like a good reason
> > > to define a new header if that happens.
> >
> > It's much better to pad the struct so that the size doesn't change.
> >
> > > At this point, is it reasonable to throw an error if more than one RULE
> > > header appears in a message?
> >
> > It is a write syscall. I'd silently discard everything else and document that
> > in the man pages. But the fanotify maintainers should really weigh in on
> > this.
> >
> > > The way I had coded this last patchset was to allow for more than one RULE
> > > header and each one would get its own record in the event.
> >
> > I do not forsee a need for this.
> >
> > > How many rules total are likely to exist?
> >
> > Could be a thousand. But I already know some missing information we'd like to
> > return to user space in an audit event, so the bit mapping on the rule number
> > might happen. I'd suggest padding one u32 for future use.
>
> A better way to handle an expansion like that would be to have a
> length/version field at the top of the struct that could be used to
> determine the size and layout of the struct.
We already do have the 'type' and 'len' fields in
struct fanotify_response_info_header. So if audit needs to pass more
information, we can define a new 'type' and either make it replace the
current struct fanotify_response_info_audit_rule or make it expand the
information in it. At least this is how we handle similar situation when
fanotify wants to report some new bits of information to userspace.
That being said if audit wants to have u32 pad in its struct
fanotify_response_info_audit_rule for future "optional" expansion I'm not
strictly opposed to that but I don't think it is a good idea. It is tricky
to safely start using the new field. Audit subsystem can define that the
kernel currently just ignores the field. And new kernel could start using
the passed information in the additional field but that is somewhat risky
because until that moment userspace can be passing random garbage in that
unused field and thus break when running on new kernel that tries to make
sense of it. Sure you can say it is broken userspace that does not properly
initialize the padding field but history has shown us multiple times that
events like these do happen and the breakage was unpleasant enough for
users that the kernel just had to revert back to ignoring the field.
Alternatively the kernel could bail with error if the new field is non-zero
but that would block new userspace using that field from running on old
kernel. But presumably the new userspace could be handling the error and
writing another response with new field zeroed out. That would be a safe
option although not very different from defining a new response type.
Ultimately I guess I'll leave it upto audit subsystem what it wants to have
in its struct fanotify_response_info_audit_rule because for fanotify
subsystem, it is just an opaque blob it is passing.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-01 7:51 ` Jan Kara
@ 2022-09-01 18:31 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-01 18:31 UTC (permalink / raw)
To: Jan Kara, Steve Grubb, Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Amir Goldstein
On Thu, Sep 1, 2022 at 3:52 AM Jan Kara <jack@suse.cz> wrote:
> On Wed 31-08-22 21:47:09, Paul Moore wrote:
> > On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > > --- a/kernel/auditsc.c
> > > > > > > > +++ b/kernel/auditsc.c
> > > > > > > > @@ -64,6 +64,7 @@
> > > > > > > > #include <uapi/linux/limits.h>
> > > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > > >
> > > > > > > > #include "audit.h"
> > > > > > > >
> > > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > > }
> > > > > > > >
> > > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > > {
> > > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > > + size_t c = len;
> > > > > > > > + char *ib = buf;
> > > > > > > > +
> > > > > > > > + if (!(len && buf)) {
> > > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > AUDIT_FANOTIFY,
> > > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > > response);
> > > > > > > > + return;
> > > > > > > > + }
> > > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > > *)buf;
> > > > > > >
> > > > > > > Since the only use of this at the moment is the
> > > > > > > fanotify_response_info_rule, why not pass the
> > > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > > can always change it if we need to in the future without affecting
> > > > > > > userspace, and it would simplify the code.
> > > > > >
> > > > > > Steve, would it make any sense for there to be more than one
> > > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > > reasonable to return -EINVAL if there is more than one?
> > > > >
> > > > > I don't see a reason for sending more than one header. What is more
> > > > > probable is the need to send additional data in that header. I was
> > > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > > padding the struct just in case it needs expanding some day.
> > > >
> > > > This doesn't exactly answer my question about multiple rules
> > > > contributing to one decision.
> > >
> > > I don't forsee that.
> > >
> > > > The need for more as yet undefined information sounds like a good reason
> > > > to define a new header if that happens.
> > >
> > > It's much better to pad the struct so that the size doesn't change.
> > >
> > > > At this point, is it reasonable to throw an error if more than one RULE
> > > > header appears in a message?
> > >
> > > It is a write syscall. I'd silently discard everything else and document that
> > > in the man pages. But the fanotify maintainers should really weigh in on
> > > this.
> > >
> > > > The way I had coded this last patchset was to allow for more than one RULE
> > > > header and each one would get its own record in the event.
> > >
> > > I do not forsee a need for this.
> > >
> > > > How many rules total are likely to exist?
> > >
> > > Could be a thousand. But I already know some missing information we'd like to
> > > return to user space in an audit event, so the bit mapping on the rule number
> > > might happen. I'd suggest padding one u32 for future use.
> >
> > A better way to handle an expansion like that would be to have a
> > length/version field at the top of the struct that could be used to
> > determine the size and layout of the struct.
>
> We already do have the 'type' and 'len' fields in
> struct fanotify_response_info_header. So if audit needs to pass more
> information, we can define a new 'type' and either make it replace the
> current struct fanotify_response_info_audit_rule or make it expand the
> information in it. At least this is how we handle similar situation when
> fanotify wants to report some new bits of information to userspace.
Perfect, I didn't know that was an option from the fanotify side; I
agree that's the right approach.
> That being said if audit wants to have u32 pad in its struct
> fanotify_response_info_audit_rule for future "optional" expansion I'm not
> strictly opposed to that but I don't think it is a good idea.
Yes, I'm not a fan of padding out this way, especially when we have
better options.
> Ultimately I guess I'll leave it upto audit subsystem what it wants to have
> in its struct fanotify_response_info_audit_rule because for fanotify
> subsystem, it is just an opaque blob it is passing.
In that case, let's stick with leveraging the type/len fields in the
fanotify_response_info_header struct, that should give us all the
flexibility we need.
Richard and Steve, it sounds like Steve is already aware of additional
information that he wants to send via the
fanotify_response_info_audit_rule struct, please include that in the
next revision of this patchset. I don't want to get this merged and
then soon after have to hack in additional info.
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-01 18:31 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-01 18:31 UTC (permalink / raw)
To: Jan Kara, Steve Grubb, Richard Guy Briggs
Cc: linux-fsdevel, Eric Paris, Linux-Audit Mailing List,
Amir Goldstein, LKML
On Thu, Sep 1, 2022 at 3:52 AM Jan Kara <jack@suse.cz> wrote:
> On Wed 31-08-22 21:47:09, Paul Moore wrote:
> > On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > > --- a/kernel/auditsc.c
> > > > > > > > +++ b/kernel/auditsc.c
> > > > > > > > @@ -64,6 +64,7 @@
> > > > > > > > #include <uapi/linux/limits.h>
> > > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > > >
> > > > > > > > #include "audit.h"
> > > > > > > >
> > > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > > }
> > > > > > > >
> > > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > > {
> > > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > > + size_t c = len;
> > > > > > > > + char *ib = buf;
> > > > > > > > +
> > > > > > > > + if (!(len && buf)) {
> > > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > AUDIT_FANOTIFY,
> > > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > > response);
> > > > > > > > + return;
> > > > > > > > + }
> > > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > > *)buf;
> > > > > > >
> > > > > > > Since the only use of this at the moment is the
> > > > > > > fanotify_response_info_rule, why not pass the
> > > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > > can always change it if we need to in the future without affecting
> > > > > > > userspace, and it would simplify the code.
> > > > > >
> > > > > > Steve, would it make any sense for there to be more than one
> > > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > > reasonable to return -EINVAL if there is more than one?
> > > > >
> > > > > I don't see a reason for sending more than one header. What is more
> > > > > probable is the need to send additional data in that header. I was
> > > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > > padding the struct just in case it needs expanding some day.
> > > >
> > > > This doesn't exactly answer my question about multiple rules
> > > > contributing to one decision.
> > >
> > > I don't forsee that.
> > >
> > > > The need for more as yet undefined information sounds like a good reason
> > > > to define a new header if that happens.
> > >
> > > It's much better to pad the struct so that the size doesn't change.
> > >
> > > > At this point, is it reasonable to throw an error if more than one RULE
> > > > header appears in a message?
> > >
> > > It is a write syscall. I'd silently discard everything else and document that
> > > in the man pages. But the fanotify maintainers should really weigh in on
> > > this.
> > >
> > > > The way I had coded this last patchset was to allow for more than one RULE
> > > > header and each one would get its own record in the event.
> > >
> > > I do not forsee a need for this.
> > >
> > > > How many rules total are likely to exist?
> > >
> > > Could be a thousand. But I already know some missing information we'd like to
> > > return to user space in an audit event, so the bit mapping on the rule number
> > > might happen. I'd suggest padding one u32 for future use.
> >
> > A better way to handle an expansion like that would be to have a
> > length/version field at the top of the struct that could be used to
> > determine the size and layout of the struct.
>
> We already do have the 'type' and 'len' fields in
> struct fanotify_response_info_header. So if audit needs to pass more
> information, we can define a new 'type' and either make it replace the
> current struct fanotify_response_info_audit_rule or make it expand the
> information in it. At least this is how we handle similar situation when
> fanotify wants to report some new bits of information to userspace.
Perfect, I didn't know that was an option from the fanotify side; I
agree that's the right approach.
> That being said if audit wants to have u32 pad in its struct
> fanotify_response_info_audit_rule for future "optional" expansion I'm not
> strictly opposed to that but I don't think it is a good idea.
Yes, I'm not a fan of padding out this way, especially when we have
better options.
> Ultimately I guess I'll leave it upto audit subsystem what it wants to have
> in its struct fanotify_response_info_audit_rule because for fanotify
> subsystem, it is just an opaque blob it is passing.
In that case, let's stick with leveraging the type/len fields in the
fanotify_response_info_header struct, that should give us all the
flexibility we need.
Richard and Steve, it sounds like Steve is already aware of additional
information that he wants to send via the
fanotify_response_info_audit_rule struct, please include that in the
next revision of this patchset. I don't want to get this merged and
then soon after have to hack in additional info.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-01 18:31 ` Paul Moore
@ 2022-09-07 18:43 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-07 18:43 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, Steve Grubb, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On 2022-09-01 14:31, Paul Moore wrote:
> On Thu, Sep 1, 2022 at 3:52 AM Jan Kara <jack@suse.cz> wrote:
> > On Wed 31-08-22 21:47:09, Paul Moore wrote:
> > > On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > > > --- a/kernel/auditsc.c
> > > > > > > > > +++ b/kernel/auditsc.c
> > > > > > > > > @@ -64,6 +64,7 @@
> > > > > > > > > #include <uapi/linux/limits.h>
> > > > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > > > >
> > > > > > > > > #include "audit.h"
> > > > > > > > >
> > > > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > > > {
> > > > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > > > + size_t c = len;
> > > > > > > > > + char *ib = buf;
> > > > > > > > > +
> > > > > > > > > + if (!(len && buf)) {
> > > > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > > AUDIT_FANOTIFY,
> > > > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > > > response);
> > > > > > > > > + return;
> > > > > > > > > + }
> > > > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > > > *)buf;
> > > > > > > >
> > > > > > > > Since the only use of this at the moment is the
> > > > > > > > fanotify_response_info_rule, why not pass the
> > > > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > > > can always change it if we need to in the future without affecting
> > > > > > > > userspace, and it would simplify the code.
> > > > > > >
> > > > > > > Steve, would it make any sense for there to be more than one
> > > > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > > > reasonable to return -EINVAL if there is more than one?
> > > > > >
> > > > > > I don't see a reason for sending more than one header. What is more
> > > > > > probable is the need to send additional data in that header. I was
> > > > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > > > padding the struct just in case it needs expanding some day.
> > > > >
> > > > > This doesn't exactly answer my question about multiple rules
> > > > > contributing to one decision.
> > > >
> > > > I don't forsee that.
> > > >
> > > > > The need for more as yet undefined information sounds like a good reason
> > > > > to define a new header if that happens.
> > > >
> > > > It's much better to pad the struct so that the size doesn't change.
> > > >
> > > > > At this point, is it reasonable to throw an error if more than one RULE
> > > > > header appears in a message?
> > > >
> > > > It is a write syscall. I'd silently discard everything else and document that
> > > > in the man pages. But the fanotify maintainers should really weigh in on
> > > > this.
> > > >
> > > > > The way I had coded this last patchset was to allow for more than one RULE
> > > > > header and each one would get its own record in the event.
> > > >
> > > > I do not forsee a need for this.
> > > >
> > > > > How many rules total are likely to exist?
> > > >
> > > > Could be a thousand. But I already know some missing information we'd like to
> > > > return to user space in an audit event, so the bit mapping on the rule number
> > > > might happen. I'd suggest padding one u32 for future use.
> > >
> > > A better way to handle an expansion like that would be to have a
> > > length/version field at the top of the struct that could be used to
> > > determine the size and layout of the struct.
> >
> > We already do have the 'type' and 'len' fields in
> > struct fanotify_response_info_header. So if audit needs to pass more
> > information, we can define a new 'type' and either make it replace the
> > current struct fanotify_response_info_audit_rule or make it expand the
> > information in it. At least this is how we handle similar situation when
> > fanotify wants to report some new bits of information to userspace.
>
> Perfect, I didn't know that was an option from the fanotify side; I
> agree that's the right approach.
This is what I expected would be the way to manage changing
requirements.
> > That being said if audit wants to have u32 pad in its struct
> > fanotify_response_info_audit_rule for future "optional" expansion I'm not
> > strictly opposed to that but I don't think it is a good idea.
>
> Yes, I'm not a fan of padding out this way, especially when we have
> better options.
Agreed.
> > Ultimately I guess I'll leave it upto audit subsystem what it wants to have
> > in its struct fanotify_response_info_audit_rule because for fanotify
> > subsystem, it is just an opaque blob it is passing.
>
> In that case, let's stick with leveraging the type/len fields in the
> fanotify_response_info_header struct, that should give us all the
> flexibility we need.
>
> Richard and Steve, it sounds like Steve is already aware of additional
> information that he wants to send via the
> fanotify_response_info_audit_rule struct, please include that in the
> next revision of this patchset. I don't want to get this merged and
> then soon after have to hack in additional info.
Steve, please define the type and name of this additional field.
I'm not particularly enthusiastic of "u32 pad;"
> paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-07 18:43 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-07 18:43 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-09-01 14:31, Paul Moore wrote:
> On Thu, Sep 1, 2022 at 3:52 AM Jan Kara <jack@suse.cz> wrote:
> > On Wed 31-08-22 21:47:09, Paul Moore wrote:
> > > On Wed, Aug 31, 2022 at 7:55 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote:
> > > > > On 2022-08-31 17:25, Steve Grubb wrote:
> > > > > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote:
> > > > > > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > > > > > index 433418d73584..f000fec52360 100644
> > > > > > > > > --- a/kernel/auditsc.c
> > > > > > > > > +++ b/kernel/auditsc.c
> > > > > > > > > @@ -64,6 +64,7 @@
> > > > > > > > > #include <uapi/linux/limits.h>
> > > > > > > > > #include <uapi/linux/netfilter/nf_tables.h>
> > > > > > > > > #include <uapi/linux/openat2.h> // struct open_how
> > > > > > > > > +#include <uapi/linux/fanotify.h>
> > > > > > > > >
> > > > > > > > > #include "audit.h"
> > > > > > > > >
> > > > > > > > > @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> > > > > > > > > context->type = AUDIT_KERN_MODULE;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > -void __audit_fanotify(u32 response)
> > > > > > > > > +void __audit_fanotify(u32 response, size_t len, char *buf)
> > > > > > > > > {
> > > > > > > > > - audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > > - AUDIT_FANOTIFY, "resp=%u", response);
> > > > > > > > > + struct fanotify_response_info_audit_rule *friar;
> > > > > > > > > + size_t c = len;
> > > > > > > > > + char *ib = buf;
> > > > > > > > > +
> > > > > > > > > + if (!(len && buf)) {
> > > > > > > > > + audit_log(audit_context(), GFP_KERNEL,
> > > > > > > > > AUDIT_FANOTIFY,
> > > > > > > > > + "resp=%u fan_type=0 fan_info=?",
> > > > > > > > > response);
> > > > > > > > > + return;
> > > > > > > > > + }
> > > > > > > > > + while (c >= sizeof(struct fanotify_response_info_header)) {
> > > > > > > > > + friar = (struct fanotify_response_info_audit_rule
> > > > > > > > > *)buf;
> > > > > > > >
> > > > > > > > Since the only use of this at the moment is the
> > > > > > > > fanotify_response_info_rule, why not pass the
> > > > > > > > fanotify_response_info_rule struct directly into this function? We
> > > > > > > > can always change it if we need to in the future without affecting
> > > > > > > > userspace, and it would simplify the code.
> > > > > > >
> > > > > > > Steve, would it make any sense for there to be more than one
> > > > > > > FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
> > > > > > > than one rule that contributes to a notify reason? If not, would it be
> > > > > > > reasonable to return -EINVAL if there is more than one?
> > > > > >
> > > > > > I don't see a reason for sending more than one header. What is more
> > > > > > probable is the need to send additional data in that header. I was
> > > > > > thinking of maybe bit mapping it in the rule number. But I'd suggest
> > > > > > padding the struct just in case it needs expanding some day.
> > > > >
> > > > > This doesn't exactly answer my question about multiple rules
> > > > > contributing to one decision.
> > > >
> > > > I don't forsee that.
> > > >
> > > > > The need for more as yet undefined information sounds like a good reason
> > > > > to define a new header if that happens.
> > > >
> > > > It's much better to pad the struct so that the size doesn't change.
> > > >
> > > > > At this point, is it reasonable to throw an error if more than one RULE
> > > > > header appears in a message?
> > > >
> > > > It is a write syscall. I'd silently discard everything else and document that
> > > > in the man pages. But the fanotify maintainers should really weigh in on
> > > > this.
> > > >
> > > > > The way I had coded this last patchset was to allow for more than one RULE
> > > > > header and each one would get its own record in the event.
> > > >
> > > > I do not forsee a need for this.
> > > >
> > > > > How many rules total are likely to exist?
> > > >
> > > > Could be a thousand. But I already know some missing information we'd like to
> > > > return to user space in an audit event, so the bit mapping on the rule number
> > > > might happen. I'd suggest padding one u32 for future use.
> > >
> > > A better way to handle an expansion like that would be to have a
> > > length/version field at the top of the struct that could be used to
> > > determine the size and layout of the struct.
> >
> > We already do have the 'type' and 'len' fields in
> > struct fanotify_response_info_header. So if audit needs to pass more
> > information, we can define a new 'type' and either make it replace the
> > current struct fanotify_response_info_audit_rule or make it expand the
> > information in it. At least this is how we handle similar situation when
> > fanotify wants to report some new bits of information to userspace.
>
> Perfect, I didn't know that was an option from the fanotify side; I
> agree that's the right approach.
This is what I expected would be the way to manage changing
requirements.
> > That being said if audit wants to have u32 pad in its struct
> > fanotify_response_info_audit_rule for future "optional" expansion I'm not
> > strictly opposed to that but I don't think it is a good idea.
>
> Yes, I'm not a fan of padding out this way, especially when we have
> better options.
Agreed.
> > Ultimately I guess I'll leave it upto audit subsystem what it wants to have
> > in its struct fanotify_response_info_audit_rule because for fanotify
> > subsystem, it is just an opaque blob it is passing.
>
> In that case, let's stick with leveraging the type/len fields in the
> fanotify_response_info_header struct, that should give us all the
> flexibility we need.
>
> Richard and Steve, it sounds like Steve is already aware of additional
> information that he wants to send via the
> fanotify_response_info_audit_rule struct, please include that in the
> next revision of this patchset. I don't want to get this merged and
> then soon after have to hack in additional info.
Steve, please define the type and name of this additional field.
I'm not particularly enthusiastic of "u32 pad;"
> paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-07 18:43 ` Richard Guy Briggs
@ 2022-09-07 20:11 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-07 20:11 UTC (permalink / raw)
To: Paul Moore, Richard Guy Briggs
Cc: Jan Kara, Linux-Audit Mailing List, LKML, linux-fsdevel,
Eric Paris, Amir Goldstein
On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > have in its struct fanotify_response_info_audit_rule because for
> > > fanotify subsystem, it is just an opaque blob it is passing.
> >
> > In that case, let's stick with leveraging the type/len fields in the
> > fanotify_response_info_header struct, that should give us all the
> > flexibility we need.
> >
> > Richard and Steve, it sounds like Steve is already aware of additional
> > information that he wants to send via the
> > fanotify_response_info_audit_rule struct, please include that in the
> > next revision of this patchset. I don't want to get this merged and
> > then soon after have to hack in additional info.
>
> Steve, please define the type and name of this additional field.
Maybe extra_data, app_data, or extra_info. Something generic that can be
reused by any application. Default to 0 if not present.
Thanks,
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-07 20:11 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-07 20:11 UTC (permalink / raw)
To: Paul Moore, Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > have in its struct fanotify_response_info_audit_rule because for
> > > fanotify subsystem, it is just an opaque blob it is passing.
> >
> > In that case, let's stick with leveraging the type/len fields in the
> > fanotify_response_info_header struct, that should give us all the
> > flexibility we need.
> >
> > Richard and Steve, it sounds like Steve is already aware of additional
> > information that he wants to send via the
> > fanotify_response_info_audit_rule struct, please include that in the
> > next revision of this patchset. I don't want to get this merged and
> > then soon after have to hack in additional info.
>
> Steve, please define the type and name of this additional field.
Maybe extra_data, app_data, or extra_info. Something generic that can be
reused by any application. Default to 0 if not present.
Thanks,
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-07 20:11 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-07 20:23 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-07 20:23 UTC (permalink / raw)
To: Steve Grubb
Cc: Richard Guy Briggs, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > > have in its struct fanotify_response_info_audit_rule because for
> > > > fanotify subsystem, it is just an opaque blob it is passing.
> > >
> > > In that case, let's stick with leveraging the type/len fields in the
> > > fanotify_response_info_header struct, that should give us all the
> > > flexibility we need.
> > >
> > > Richard and Steve, it sounds like Steve is already aware of additional
> > > information that he wants to send via the
> > > fanotify_response_info_audit_rule struct, please include that in the
> > > next revision of this patchset. I don't want to get this merged and
> > > then soon after have to hack in additional info.
> >
> > Steve, please define the type and name of this additional field.
>
> Maybe extra_data, app_data, or extra_info. Something generic that can be
> reused by any application. Default to 0 if not present.
I think the point is being missed ... The idea is to not speculate on
additional fields, as discussed we have ways to handle that, the issue
was that Steve implied that he already had ideas for "things" he
wanted to add. If there are "things" that need to be added, let's do
that now, however if there is just speculation that maybe someday we
might need to add something else we can leave that until later.
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-07 20:23 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-07 20:23 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > > have in its struct fanotify_response_info_audit_rule because for
> > > > fanotify subsystem, it is just an opaque blob it is passing.
> > >
> > > In that case, let's stick with leveraging the type/len fields in the
> > > fanotify_response_info_header struct, that should give us all the
> > > flexibility we need.
> > >
> > > Richard and Steve, it sounds like Steve is already aware of additional
> > > information that he wants to send via the
> > > fanotify_response_info_audit_rule struct, please include that in the
> > > next revision of this patchset. I don't want to get this merged and
> > > then soon after have to hack in additional info.
> >
> > Steve, please define the type and name of this additional field.
>
> Maybe extra_data, app_data, or extra_info. Something generic that can be
> reused by any application. Default to 0 if not present.
I think the point is being missed ... The idea is to not speculate on
additional fields, as discussed we have ways to handle that, the issue
was that Steve implied that he already had ideas for "things" he
wanted to add. If there are "things" that need to be added, let's do
that now, however if there is just speculation that maybe someday we
might need to add something else we can leave that until later.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-07 20:23 ` Paul Moore
@ 2022-09-08 21:14 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-08 21:14 UTC (permalink / raw)
To: Paul Moore
Cc: Richard Guy Briggs, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > > Ultimately I guess I'll leave it upto audit subsystem what it wants
> > > > > to
> > > > > have in its struct fanotify_response_info_audit_rule because for
> > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > >
> > > > In that case, let's stick with leveraging the type/len fields in the
> > > > fanotify_response_info_header struct, that should give us all the
> > > > flexibility we need.
> > > >
> > > > Richard and Steve, it sounds like Steve is already aware of
> > > > additional
> > > > information that he wants to send via the
> > > > fanotify_response_info_audit_rule struct, please include that in the
> > > > next revision of this patchset. I don't want to get this merged and
> > > > then soon after have to hack in additional info.
> > >
> > > Steve, please define the type and name of this additional field.
> >
> > Maybe extra_data, app_data, or extra_info. Something generic that can be
> > reused by any application. Default to 0 if not present.
>
> I think the point is being missed ... The idea is to not speculate on
> additional fields, as discussed we have ways to handle that, the issue
> was that Steve implied that he already had ideas for "things" he
> wanted to add. If there are "things" that need to be added, let's do
> that now, however if there is just speculation that maybe someday we
> might need to add something else we can leave that until later.
This is not speculation. I know what I want to put there. I know you want to
pin it down to exactly what it is. However, when this started a couple years
back, one of the concerns was that we're building something specific to 1 user
of fanotify. And that it would be better for all future users to have a
generic facility that everyone could use if they wanted to. That's why I'm
suggesting something generic, its so this is not special purpose that doesn't
fit any other use case.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-08 21:14 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-08 21:14 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > > Ultimately I guess I'll leave it upto audit subsystem what it wants
> > > > > to
> > > > > have in its struct fanotify_response_info_audit_rule because for
> > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > >
> > > > In that case, let's stick with leveraging the type/len fields in the
> > > > fanotify_response_info_header struct, that should give us all the
> > > > flexibility we need.
> > > >
> > > > Richard and Steve, it sounds like Steve is already aware of
> > > > additional
> > > > information that he wants to send via the
> > > > fanotify_response_info_audit_rule struct, please include that in the
> > > > next revision of this patchset. I don't want to get this merged and
> > > > then soon after have to hack in additional info.
> > >
> > > Steve, please define the type and name of this additional field.
> >
> > Maybe extra_data, app_data, or extra_info. Something generic that can be
> > reused by any application. Default to 0 if not present.
>
> I think the point is being missed ... The idea is to not speculate on
> additional fields, as discussed we have ways to handle that, the issue
> was that Steve implied that he already had ideas for "things" he
> wanted to add. If there are "things" that need to be added, let's do
> that now, however if there is just speculation that maybe someday we
> might need to add something else we can leave that until later.
This is not speculation. I know what I want to put there. I know you want to
pin it down to exactly what it is. However, when this started a couple years
back, one of the concerns was that we're building something specific to 1 user
of fanotify. And that it would be better for all future users to have a
generic facility that everyone could use if they wanted to. That's why I'm
suggesting something generic, its so this is not special purpose that doesn't
fit any other use case.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-08 21:14 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-08 21:22 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-08 21:22 UTC (permalink / raw)
To: Steve Grubb
Cc: Richard Guy Briggs, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > > > Ultimately I guess I'll leave it upto audit subsystem what it wants
> > > > > > to
> > > > > > have in its struct fanotify_response_info_audit_rule because for
> > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > >
> > > > > In that case, let's stick with leveraging the type/len fields in the
> > > > > fanotify_response_info_header struct, that should give us all the
> > > > > flexibility we need.
> > > > >
> > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > additional
> > > > > information that he wants to send via the
> > > > > fanotify_response_info_audit_rule struct, please include that in the
> > > > > next revision of this patchset. I don't want to get this merged and
> > > > > then soon after have to hack in additional info.
> > > >
> > > > Steve, please define the type and name of this additional field.
> > >
> > > Maybe extra_data, app_data, or extra_info. Something generic that can be
> > > reused by any application. Default to 0 if not present.
> >
> > I think the point is being missed ... The idea is to not speculate on
> > additional fields, as discussed we have ways to handle that, the issue
> > was that Steve implied that he already had ideas for "things" he
> > wanted to add. If there are "things" that need to be added, let's do
> > that now, however if there is just speculation that maybe someday we
> > might need to add something else we can leave that until later.
>
> This is not speculation. I know what I want to put there. I know you want to
> pin it down to exactly what it is. However, when this started a couple years
> back, one of the concerns was that we're building something specific to 1 user
> of fanotify. And that it would be better for all future users to have a
> generic facility that everyone could use if they wanted to. That's why I'm
> suggesting something generic, its so this is not special purpose that doesn't
> fit any other use case.
Well, we are talking specifically about fanotify in this thread and
dealing with data structures that are specific to fanotify. I can
understand wanting to future proof things, but based on what we've
seen in this thread I think we are all set in this regard.
You mention that you know what you want to put in the struct, why not
share the details with all of us so we are all on the same page and
can have a proper discussion.
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-08 21:22 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-08 21:22 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > > > Ultimately I guess I'll leave it upto audit subsystem what it wants
> > > > > > to
> > > > > > have in its struct fanotify_response_info_audit_rule because for
> > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > >
> > > > > In that case, let's stick with leveraging the type/len fields in the
> > > > > fanotify_response_info_header struct, that should give us all the
> > > > > flexibility we need.
> > > > >
> > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > additional
> > > > > information that he wants to send via the
> > > > > fanotify_response_info_audit_rule struct, please include that in the
> > > > > next revision of this patchset. I don't want to get this merged and
> > > > > then soon after have to hack in additional info.
> > > >
> > > > Steve, please define the type and name of this additional field.
> > >
> > > Maybe extra_data, app_data, or extra_info. Something generic that can be
> > > reused by any application. Default to 0 if not present.
> >
> > I think the point is being missed ... The idea is to not speculate on
> > additional fields, as discussed we have ways to handle that, the issue
> > was that Steve implied that he already had ideas for "things" he
> > wanted to add. If there are "things" that need to be added, let's do
> > that now, however if there is just speculation that maybe someday we
> > might need to add something else we can leave that until later.
>
> This is not speculation. I know what I want to put there. I know you want to
> pin it down to exactly what it is. However, when this started a couple years
> back, one of the concerns was that we're building something specific to 1 user
> of fanotify. And that it would be better for all future users to have a
> generic facility that everyone could use if they wanted to. That's why I'm
> suggesting something generic, its so this is not special purpose that doesn't
> fit any other use case.
Well, we are talking specifically about fanotify in this thread and
dealing with data structures that are specific to fanotify. I can
understand wanting to future proof things, but based on what we've
seen in this thread I think we are all set in this regard.
You mention that you know what you want to put in the struct, why not
share the details with all of us so we are all on the same page and
can have a proper discussion.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-08 21:22 ` Paul Moore
@ 2022-09-09 2:20 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 2:20 UTC (permalink / raw)
To: Paul Moore
Cc: Richard Guy Briggs, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
wrote:
> > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > wants
> > > > > > > to
> > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > for
> > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > >
> > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > the
> > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > flexibility we need.
> > > > > >
> > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > additional
> > > > > > information that he wants to send via the
> > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > the
> > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > and
> > > > > > then soon after have to hack in additional info.
> > > > >
> > > > > Steve, please define the type and name of this additional field.
> > > >
> > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > be
> > > > reused by any application. Default to 0 if not present.
> > >
> > > I think the point is being missed ... The idea is to not speculate on
> > > additional fields, as discussed we have ways to handle that, the issue
> > > was that Steve implied that he already had ideas for "things" he
> > > wanted to add. If there are "things" that need to be added, let's do
> > > that now, however if there is just speculation that maybe someday we
> > > might need to add something else we can leave that until later.
> >
> > This is not speculation. I know what I want to put there. I know you want
> > to pin it down to exactly what it is. However, when this started a
> > couple years back, one of the concerns was that we're building something
> > specific to 1 user of fanotify. And that it would be better for all
> > future users to have a generic facility that everyone could use if they
> > wanted to. That's why I'm suggesting something generic, its so this is
> > not special purpose that doesn't fit any other use case.
>
> Well, we are talking specifically about fanotify in this thread and
> dealing with data structures that are specific to fanotify. I can
> understand wanting to future proof things, but based on what we've
> seen in this thread I think we are all set in this regard.
I'm trying to abide by what was suggested by the fs-devel folks. I can live
with it. But if you want to make something non-generic for all users of
fanotify, call the new field "trusted". This would decern when a decision was
made because the file was untrusted or access denied for another reason.
> You mention that you know what you want to put in the struct, why not
> share the details with all of us so we are all on the same page and
> can have a proper discussion.
Because I want to abide by the original agreement and not impose opinionated
requirements that serve no one else. I'd rather have something anyone can
use. I want to play nice.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-09 2:20 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 2:20 UTC (permalink / raw)
To: Paul Moore
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
wrote:
> > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > wants
> > > > > > > to
> > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > for
> > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > >
> > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > the
> > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > flexibility we need.
> > > > > >
> > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > additional
> > > > > > information that he wants to send via the
> > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > the
> > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > and
> > > > > > then soon after have to hack in additional info.
> > > > >
> > > > > Steve, please define the type and name of this additional field.
> > > >
> > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > be
> > > > reused by any application. Default to 0 if not present.
> > >
> > > I think the point is being missed ... The idea is to not speculate on
> > > additional fields, as discussed we have ways to handle that, the issue
> > > was that Steve implied that he already had ideas for "things" he
> > > wanted to add. If there are "things" that need to be added, let's do
> > > that now, however if there is just speculation that maybe someday we
> > > might need to add something else we can leave that until later.
> >
> > This is not speculation. I know what I want to put there. I know you want
> > to pin it down to exactly what it is. However, when this started a
> > couple years back, one of the concerns was that we're building something
> > specific to 1 user of fanotify. And that it would be better for all
> > future users to have a generic facility that everyone could use if they
> > wanted to. That's why I'm suggesting something generic, its so this is
> > not special purpose that doesn't fit any other use case.
>
> Well, we are talking specifically about fanotify in this thread and
> dealing with data structures that are specific to fanotify. I can
> understand wanting to future proof things, but based on what we've
> seen in this thread I think we are all set in this regard.
I'm trying to abide by what was suggested by the fs-devel folks. I can live
with it. But if you want to make something non-generic for all users of
fanotify, call the new field "trusted". This would decern when a decision was
made because the file was untrusted or access denied for another reason.
> You mention that you know what you want to put in the struct, why not
> share the details with all of us so we are all on the same page and
> can have a proper discussion.
Because I want to abide by the original agreement and not impose opinionated
requirements that serve no one else. I'd rather have something anyone can
use. I want to play nice.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 2:20 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-09 2:41 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 2:41 UTC (permalink / raw)
To: Steve Grubb
Cc: Paul Moore, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On 2022-09-08 22:20, Steve Grubb wrote:
> On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> > On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
> wrote:
> > > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > > wants
> > > > > > > > to
> > > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > > for
> > > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > > >
> > > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > > the
> > > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > > flexibility we need.
> > > > > > >
> > > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > > additional
> > > > > > > information that he wants to send via the
> > > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > > the
> > > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > > and
> > > > > > > then soon after have to hack in additional info.
> > > > > >
> > > > > > Steve, please define the type and name of this additional field.
> > > > >
> > > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > > be
> > > > > reused by any application. Default to 0 if not present.
> > > >
> > > > I think the point is being missed ... The idea is to not speculate on
> > > > additional fields, as discussed we have ways to handle that, the issue
> > > > was that Steve implied that he already had ideas for "things" he
> > > > wanted to add. If there are "things" that need to be added, let's do
> > > > that now, however if there is just speculation that maybe someday we
> > > > might need to add something else we can leave that until later.
> > >
> > > This is not speculation. I know what I want to put there. I know you want
> > > to pin it down to exactly what it is. However, when this started a
> > > couple years back, one of the concerns was that we're building something
> > > specific to 1 user of fanotify. And that it would be better for all
> > > future users to have a generic facility that everyone could use if they
> > > wanted to. That's why I'm suggesting something generic, its so this is
> > > not special purpose that doesn't fit any other use case.
> >
> > Well, we are talking specifically about fanotify in this thread and
> > dealing with data structures that are specific to fanotify. I can
> > understand wanting to future proof things, but based on what we've
> > seen in this thread I think we are all set in this regard.
>
> I'm trying to abide by what was suggested by the fs-devel folks. I can live
> with it. But if you want to make something non-generic for all users of
> fanotify, call the new field "trusted". This would decern when a decision was
> made because the file was untrusted or access denied for another reason.
So, "u32 trusted;" ? How would you like that formatted?
"fan_trust={0|1}"
> > You mention that you know what you want to put in the struct, why not
> > share the details with all of us so we are all on the same page and
> > can have a proper discussion.
>
> Because I want to abide by the original agreement and not impose opinionated
> requirements that serve no one else. I'd rather have something anyone can
> use. I want to play nice.
If someone else wants to use something, why not give them a type of
their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
however they like?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-09 2:41 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 2:41 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-09-08 22:20, Steve Grubb wrote:
> On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> > On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
> wrote:
> > > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > > wants
> > > > > > > > to
> > > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > > for
> > > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > > >
> > > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > > the
> > > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > > flexibility we need.
> > > > > > >
> > > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > > additional
> > > > > > > information that he wants to send via the
> > > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > > the
> > > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > > and
> > > > > > > then soon after have to hack in additional info.
> > > > > >
> > > > > > Steve, please define the type and name of this additional field.
> > > > >
> > > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > > be
> > > > > reused by any application. Default to 0 if not present.
> > > >
> > > > I think the point is being missed ... The idea is to not speculate on
> > > > additional fields, as discussed we have ways to handle that, the issue
> > > > was that Steve implied that he already had ideas for "things" he
> > > > wanted to add. If there are "things" that need to be added, let's do
> > > > that now, however if there is just speculation that maybe someday we
> > > > might need to add something else we can leave that until later.
> > >
> > > This is not speculation. I know what I want to put there. I know you want
> > > to pin it down to exactly what it is. However, when this started a
> > > couple years back, one of the concerns was that we're building something
> > > specific to 1 user of fanotify. And that it would be better for all
> > > future users to have a generic facility that everyone could use if they
> > > wanted to. That's why I'm suggesting something generic, its so this is
> > > not special purpose that doesn't fit any other use case.
> >
> > Well, we are talking specifically about fanotify in this thread and
> > dealing with data structures that are specific to fanotify. I can
> > understand wanting to future proof things, but based on what we've
> > seen in this thread I think we are all set in this regard.
>
> I'm trying to abide by what was suggested by the fs-devel folks. I can live
> with it. But if you want to make something non-generic for all users of
> fanotify, call the new field "trusted". This would decern when a decision was
> made because the file was untrusted or access denied for another reason.
So, "u32 trusted;" ? How would you like that formatted?
"fan_trust={0|1}"
> > You mention that you know what you want to put in the struct, why not
> > share the details with all of us so we are all on the same page and
> > can have a proper discussion.
>
> Because I want to abide by the original agreement and not impose opinionated
> requirements that serve no one else. I'd rather have something anyone can
> use. I want to play nice.
If someone else wants to use something, why not give them a type of
their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
however they like?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 2:41 ` Richard Guy Briggs
@ 2022-09-09 3:25 ` Paul Moore
-1 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-09 3:25 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Steve Grubb, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Thu, Sep 8, 2022 at 10:41 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2022-09-08 22:20, Steve Grubb wrote:
> > On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> > > On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
> > wrote:
> > > > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > > > wants
> > > > > > > > > to
> > > > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > > > for
> > > > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > > > >
> > > > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > > > the
> > > > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > > > flexibility we need.
> > > > > > > >
> > > > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > > > additional
> > > > > > > > information that he wants to send via the
> > > > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > > > the
> > > > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > > > and
> > > > > > > > then soon after have to hack in additional info.
> > > > > > >
> > > > > > > Steve, please define the type and name of this additional field.
> > > > > >
> > > > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > > > be
> > > > > > reused by any application. Default to 0 if not present.
> > > > >
> > > > > I think the point is being missed ... The idea is to not speculate on
> > > > > additional fields, as discussed we have ways to handle that, the issue
> > > > > was that Steve implied that he already had ideas for "things" he
> > > > > wanted to add. If there are "things" that need to be added, let's do
> > > > > that now, however if there is just speculation that maybe someday we
> > > > > might need to add something else we can leave that until later.
> > > >
> > > > This is not speculation. I know what I want to put there. I know you want
> > > > to pin it down to exactly what it is. However, when this started a
> > > > couple years back, one of the concerns was that we're building something
> > > > specific to 1 user of fanotify. And that it would be better for all
> > > > future users to have a generic facility that everyone could use if they
> > > > wanted to. That's why I'm suggesting something generic, its so this is
> > > > not special purpose that doesn't fit any other use case.
> > >
> > > Well, we are talking specifically about fanotify in this thread and
> > > dealing with data structures that are specific to fanotify. I can
> > > understand wanting to future proof things, but based on what we've
> > > seen in this thread I think we are all set in this regard.
> >
> > I'm trying to abide by what was suggested by the fs-devel folks. I can live
> > with it. But if you want to make something non-generic for all users of
> > fanotify, call the new field "trusted". This would decern when a decision was
> > made because the file was untrusted or access denied for another reason.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
>
> > > You mention that you know what you want to put in the struct, why not
> > > share the details with all of us so we are all on the same page and
> > > can have a proper discussion.
> >
> > Because I want to abide by the original agreement and not impose opinionated
> > requirements that serve no one else. I'd rather have something anyone can
> > use. I want to play nice.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Yes, exactly. The struct is very clearly specific to both fanotify
and audit, I see no reason why it needs to be made generic for use by
other subsystems when other mechanisms exist to support them.
--
paul-moore.com
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-09 3:25 ` Paul Moore
0 siblings, 0 replies; 91+ messages in thread
From: Paul Moore @ 2022-09-09 3:25 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Thu, Sep 8, 2022 at 10:41 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2022-09-08 22:20, Steve Grubb wrote:
> > On Thursday, September 8, 2022 5:22:15 PM EDT Paul Moore wrote:
> > > On Thu, Sep 8, 2022 at 5:14 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Wednesday, September 7, 2022 4:23:49 PM EDT Paul Moore wrote:
> > > > > On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@redhat.com> wrote:
> > > > > > On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs
> > wrote:
> > > > > > > > > Ultimately I guess I'll leave it upto audit subsystem what it
> > > > > > > > > wants
> > > > > > > > > to
> > > > > > > > > have in its struct fanotify_response_info_audit_rule because
> > > > > > > > > for
> > > > > > > > > fanotify subsystem, it is just an opaque blob it is passing.
> > > > > > > >
> > > > > > > > In that case, let's stick with leveraging the type/len fields in
> > > > > > > > the
> > > > > > > > fanotify_response_info_header struct, that should give us all the
> > > > > > > > flexibility we need.
> > > > > > > >
> > > > > > > > Richard and Steve, it sounds like Steve is already aware of
> > > > > > > > additional
> > > > > > > > information that he wants to send via the
> > > > > > > > fanotify_response_info_audit_rule struct, please include that in
> > > > > > > > the
> > > > > > > > next revision of this patchset. I don't want to get this merged
> > > > > > > > and
> > > > > > > > then soon after have to hack in additional info.
> > > > > > >
> > > > > > > Steve, please define the type and name of this additional field.
> > > > > >
> > > > > > Maybe extra_data, app_data, or extra_info. Something generic that can
> > > > > > be
> > > > > > reused by any application. Default to 0 if not present.
> > > > >
> > > > > I think the point is being missed ... The idea is to not speculate on
> > > > > additional fields, as discussed we have ways to handle that, the issue
> > > > > was that Steve implied that he already had ideas for "things" he
> > > > > wanted to add. If there are "things" that need to be added, let's do
> > > > > that now, however if there is just speculation that maybe someday we
> > > > > might need to add something else we can leave that until later.
> > > >
> > > > This is not speculation. I know what I want to put there. I know you want
> > > > to pin it down to exactly what it is. However, when this started a
> > > > couple years back, one of the concerns was that we're building something
> > > > specific to 1 user of fanotify. And that it would be better for all
> > > > future users to have a generic facility that everyone could use if they
> > > > wanted to. That's why I'm suggesting something generic, its so this is
> > > > not special purpose that doesn't fit any other use case.
> > >
> > > Well, we are talking specifically about fanotify in this thread and
> > > dealing with data structures that are specific to fanotify. I can
> > > understand wanting to future proof things, but based on what we've
> > > seen in this thread I think we are all set in this regard.
> >
> > I'm trying to abide by what was suggested by the fs-devel folks. I can live
> > with it. But if you want to make something non-generic for all users of
> > fanotify, call the new field "trusted". This would decern when a decision was
> > made because the file was untrusted or access denied for another reason.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
>
> > > You mention that you know what you want to put in the struct, why not
> > > share the details with all of us so we are all on the same page and
> > > can have a proper discussion.
> >
> > Because I want to abide by the original agreement and not impose opinionated
> > requirements that serve no one else. I'd rather have something anyone can
> > use. I want to play nice.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Yes, exactly. The struct is very clearly specific to both fanotify
and audit, I see no reason why it needs to be made generic for use by
other subsystems when other mechanisms exist to support them.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 2:41 ` Richard Guy Briggs
@ 2022-09-09 4:03 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 4:03 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Paul Moore, Jan Kara, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > I'm trying to abide by what was suggested by the fs-devel folks. I can
> > live with it. But if you want to make something non-generic for all
> > users of fanotify, call the new field "trusted". This would decern when
> > a decision was made because the file was untrusted or access denied for
> > another reason.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
So how does this play out if there is another user? Do they want a num= and
trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
which is not good. I'd rather suggest something generic that can be
interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
then followed by info0= info1= the interpretation of those solely depend on
fan_type. If the fan_type does not need both, then any interpretation skips
what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
for that format. But make this pivot on fan_type and not actual names.
> > > You mention that you know what you want to put in the struct, why not
> > > share the details with all of us so we are all on the same page and
> > > can have a proper discussion.
> >
> > Because I want to abide by the original agreement and not impose
> > opinionated requirements that serve no one else. I'd rather have
> > something anyone can use. I want to play nice.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Please, let's keep AUDIT_FANOTIFY normalized but pivot on fan_type.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-09 4:03 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 4:03 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > I'm trying to abide by what was suggested by the fs-devel folks. I can
> > live with it. But if you want to make something non-generic for all
> > users of fanotify, call the new field "trusted". This would decern when
> > a decision was made because the file was untrusted or access denied for
> > another reason.
>
> So, "u32 trusted;" ? How would you like that formatted?
> "fan_trust={0|1}"
So how does this play out if there is another user? Do they want a num= and
trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
which is not good. I'd rather suggest something generic that can be
interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
then followed by info0= info1= the interpretation of those solely depend on
fan_type. If the fan_type does not need both, then any interpretation skips
what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
for that format. But make this pivot on fan_type and not actual names.
> > > You mention that you know what you want to put in the struct, why not
> > > share the details with all of us so we are all on the same page and
> > > can have a proper discussion.
> >
> > Because I want to abide by the original agreement and not impose
> > opinionated requirements that serve no one else. I'd rather have
> > something anyone can use. I want to play nice.
>
> If someone else wants to use something, why not give them a type of
> their own other than FAN_RESPONSE_INFO_AUDIT_RULE that they can shape
> however they like?
Please, let's keep AUDIT_FANOTIFY normalized but pivot on fan_type.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 4:03 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-09 11:09 ` Jan Kara
-1 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-09-09 11:09 UTC (permalink / raw)
To: Steve Grubb
Cc: Richard Guy Briggs, Paul Moore, Jan Kara,
Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Amir Goldstein
Hello Steve!
On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > I'm trying to abide by what was suggested by the fs-devel folks. I can
> > > live with it. But if you want to make something non-generic for all
> > > users of fanotify, call the new field "trusted". This would decern when
> > > a decision was made because the file was untrusted or access denied for
> > > another reason.
> >
> > So, "u32 trusted;" ? How would you like that formatted?
> > "fan_trust={0|1}"
>
> So how does this play out if there is another user? Do they want a num= and
> trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
> which is not good. I'd rather suggest something generic that can be
> interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
> then followed by info0= info1= the interpretation of those solely depend on
> fan_type. If the fan_type does not need both, then any interpretation skips
> what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
> for that format. But make this pivot on fan_type and not actual names.
So I think there is some misunderstanding so let me maybe spell out in
detail how I see things so that we can get on the same page:
It was a requirement from me (and probably Amir) that there is a generic
way to attach additional info to a response to fanotify permission event.
This is achieved by defining:
struct fanotify_response_info_header {
__u8 type;
__u8 pad;
__u16 len;
};
which is a generic header and kernel can based on 'len' field decide how
large the response structure is (to safely copy it from userspace) and
based on 'type' field it can decide who should be the recipient of this
extra information (or generally what to do with it). So any additional
info needs to start with this header.
Then there is:
struct fanotify_response_info_audit_rule {
struct fanotify_response_info_header hdr;
__u32 audit_rule;
};
which properly starts with the header and hdr.type is expected to be
FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
subsystem's responsibility. Fanotify code will just pass this as an opaque
blob to the audit subsystem.
So if you know audit subsystem will also need some other field together
with 'audit_rule' now is a good time to add it and it doesn't have to be
useful for anybody else besides audit. If someone else will need other
information passed along with the response, he will append structure with
another header with different 'type' field. In principle, there can be
multiple structures appended to fanotify response like
<hdr> <data> <hdr> <data> ...
and fanotify subsystem will just pass them to different receivers based
on the type in 'hdr' field.
Also if audit needs to pass even more information along with the respose,
we can define a new 'type' for it. But the 'type' space is not infinite so
I'd prefer this does not happen too often...
I hope this clears out things a bit.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-09 11:09 ` Jan Kara
0 siblings, 0 replies; 91+ messages in thread
From: Jan Kara @ 2022-09-09 11:09 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
Hello Steve!
On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > I'm trying to abide by what was suggested by the fs-devel folks. I can
> > > live with it. But if you want to make something non-generic for all
> > > users of fanotify, call the new field "trusted". This would decern when
> > > a decision was made because the file was untrusted or access denied for
> > > another reason.
> >
> > So, "u32 trusted;" ? How would you like that formatted?
> > "fan_trust={0|1}"
>
> So how does this play out if there is another user? Do they want a num= and
> trust= if not, then the AUDIT_FANOTIFY record will have multiple formats
> which is not good. I'd rather suggest something generic that can be
> interpreted based on who's attached to fanotify. IOW we have a fan_type=0 and
> then followed by info0= info1= the interpretation of those solely depend on
> fan_type. If the fan_type does not need both, then any interpretation skips
> what it doesn't need. If fan_type=1, then it follows what arg0= and arg1= is
> for that format. But make this pivot on fan_type and not actual names.
So I think there is some misunderstanding so let me maybe spell out in
detail how I see things so that we can get on the same page:
It was a requirement from me (and probably Amir) that there is a generic
way to attach additional info to a response to fanotify permission event.
This is achieved by defining:
struct fanotify_response_info_header {
__u8 type;
__u8 pad;
__u16 len;
};
which is a generic header and kernel can based on 'len' field decide how
large the response structure is (to safely copy it from userspace) and
based on 'type' field it can decide who should be the recipient of this
extra information (or generally what to do with it). So any additional
info needs to start with this header.
Then there is:
struct fanotify_response_info_audit_rule {
struct fanotify_response_info_header hdr;
__u32 audit_rule;
};
which properly starts with the header and hdr.type is expected to be
FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
subsystem's responsibility. Fanotify code will just pass this as an opaque
blob to the audit subsystem.
So if you know audit subsystem will also need some other field together
with 'audit_rule' now is a good time to add it and it doesn't have to be
useful for anybody else besides audit. If someone else will need other
information passed along with the response, he will append structure with
another header with different 'type' field. In principle, there can be
multiple structures appended to fanotify response like
<hdr> <data> <hdr> <data> ...
and fanotify subsystem will just pass them to different receivers based
on the type in 'hdr' field.
Also if audit needs to pass even more information along with the respose,
we can define a new 'type' for it. But the 'type' space is not infinite so
I'd prefer this does not happen too often...
I hope this clears out things a bit.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 11:09 ` Jan Kara
@ 2022-09-09 14:22 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 14:22 UTC (permalink / raw)
To: Jan Kara
Cc: Richard Guy Briggs, Paul Moore, Jan Kara,
Linux-Audit Mailing List, LKML, linux-fsdevel, Eric Paris,
Amir Goldstein
On Friday, September 9, 2022 7:09:44 AM EDT Jan Kara wrote:
> Hello Steve!
>
> On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> > On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > > I'm trying to abide by what was suggested by the fs-devel folks. I
> > > > can
> > > > live with it. But if you want to make something non-generic for all
> > > > users of fanotify, call the new field "trusted". This would decern
> > > > when
> > > > a decision was made because the file was untrusted or access denied
> > > > for
> > > > another reason.
> > >
> > > So, "u32 trusted;" ? How would you like that formatted?
> > > "fan_trust={0|1}"
> >
> > So how does this play out if there is another user? Do they want a num=
> > and trust= if not, then the AUDIT_FANOTIFY record will have multiple
> > formats which is not good. I'd rather suggest something generic that can
> > be interpreted based on who's attached to fanotify. IOW we have a
> > fan_type=0 and then followed by info0= info1= the interpretation of
> > those solely depend on fan_type. If the fan_type does not need both,
> > then any interpretation skips what it doesn't need. If fan_type=1, then
> > it follows what arg0= and arg1= is for that format. But make this pivot
> > on fan_type and not actual names.
> So I think there is some misunderstanding so let me maybe spell out in
> detail how I see things so that we can get on the same page:
>
> It was a requirement from me (and probably Amir) that there is a generic
> way to attach additional info to a response to fanotify permission event.
> This is achieved by defining:
>
> struct fanotify_response_info_header {
> __u8 type;
> __u8 pad;
> __u16 len;
> };
>
> which is a generic header and kernel can based on 'len' field decide how
> large the response structure is (to safely copy it from userspace) and
> based on 'type' field it can decide who should be the recipient of this
> extra information (or generally what to do with it). So any additional
> info needs to start with this header.
>
> Then there is:
>
> struct fanotify_response_info_audit_rule {
> struct fanotify_response_info_header hdr;
> __u32 audit_rule;
> };
>
> which properly starts with the header and hdr.type is expected to be
> FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
> FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
> subsystem's responsibility. Fanotify code will just pass this as an opaque
> blob to the audit subsystem.
>
> So if you know audit subsystem will also need some other field together
> with 'audit_rule' now is a good time to add it and it doesn't have to be
> useful for anybody else besides audit. If someone else will need other
> information passed along with the response, he will append structure with
> another header with different 'type' field. In principle, there can be
> multiple structures appended to fanotify response like
>
> <hdr> <data> <hdr> <data> ...
>
> and fanotify subsystem will just pass them to different receivers based
> on the type in 'hdr' field.
>
> Also if audit needs to pass even more information along with the respose,
> we can define a new 'type' for it. But the 'type' space is not infinite so
> I'd prefer this does not happen too often...
>
> I hope this clears out things a bit.
Yes. Thank you.
Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
unknown.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-09 14:22 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 14:22 UTC (permalink / raw)
To: Jan Kara
Cc: Jan Kara, Richard Guy Briggs, Amir Goldstein, LKML,
Linux-Audit Mailing List, linux-fsdevel, Eric Paris
On Friday, September 9, 2022 7:09:44 AM EDT Jan Kara wrote:
> Hello Steve!
>
> On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> > On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > > I'm trying to abide by what was suggested by the fs-devel folks. I
> > > > can
> > > > live with it. But if you want to make something non-generic for all
> > > > users of fanotify, call the new field "trusted". This would decern
> > > > when
> > > > a decision was made because the file was untrusted or access denied
> > > > for
> > > > another reason.
> > >
> > > So, "u32 trusted;" ? How would you like that formatted?
> > > "fan_trust={0|1}"
> >
> > So how does this play out if there is another user? Do they want a num=
> > and trust= if not, then the AUDIT_FANOTIFY record will have multiple
> > formats which is not good. I'd rather suggest something generic that can
> > be interpreted based on who's attached to fanotify. IOW we have a
> > fan_type=0 and then followed by info0= info1= the interpretation of
> > those solely depend on fan_type. If the fan_type does not need both,
> > then any interpretation skips what it doesn't need. If fan_type=1, then
> > it follows what arg0= and arg1= is for that format. But make this pivot
> > on fan_type and not actual names.
> So I think there is some misunderstanding so let me maybe spell out in
> detail how I see things so that we can get on the same page:
>
> It was a requirement from me (and probably Amir) that there is a generic
> way to attach additional info to a response to fanotify permission event.
> This is achieved by defining:
>
> struct fanotify_response_info_header {
> __u8 type;
> __u8 pad;
> __u16 len;
> };
>
> which is a generic header and kernel can based on 'len' field decide how
> large the response structure is (to safely copy it from userspace) and
> based on 'type' field it can decide who should be the recipient of this
> extra information (or generally what to do with it). So any additional
> info needs to start with this header.
>
> Then there is:
>
> struct fanotify_response_info_audit_rule {
> struct fanotify_response_info_header hdr;
> __u32 audit_rule;
> };
>
> which properly starts with the header and hdr.type is expected to be
> FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
> FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
> subsystem's responsibility. Fanotify code will just pass this as an opaque
> blob to the audit subsystem.
>
> So if you know audit subsystem will also need some other field together
> with 'audit_rule' now is a good time to add it and it doesn't have to be
> useful for anybody else besides audit. If someone else will need other
> information passed along with the response, he will append structure with
> another header with different 'type' field. In principle, there can be
> multiple structures appended to fanotify response like
>
> <hdr> <data> <hdr> <data> ...
>
> and fanotify subsystem will just pass them to different receivers based
> on the type in 'hdr' field.
>
> Also if audit needs to pass even more information along with the respose,
> we can define a new 'type' for it. But the 'type' space is not infinite so
> I'd prefer this does not happen too often...
>
> I hope this clears out things a bit.
Yes. Thank you.
Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
unknown.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 14:22 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-09 14:38 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 14:38 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Paul Moore, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On 2022-09-09 10:22, Steve Grubb wrote:
> On Friday, September 9, 2022 7:09:44 AM EDT Jan Kara wrote:
> > Hello Steve!
> >
> > On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> > > On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > > > I'm trying to abide by what was suggested by the fs-devel folks. I
> > > > > can
> > > > > live with it. But if you want to make something non-generic for all
> > > > > users of fanotify, call the new field "trusted". This would decern
> > > > > when
> > > > > a decision was made because the file was untrusted or access denied
> > > > > for
> > > > > another reason.
> > > >
> > > > So, "u32 trusted;" ? How would you like that formatted?
> > > > "fan_trust={0|1}"
> > >
> > > So how does this play out if there is another user? Do they want a num=
> > > and trust= if not, then the AUDIT_FANOTIFY record will have multiple
> > > formats which is not good. I'd rather suggest something generic that can
> > > be interpreted based on who's attached to fanotify. IOW we have a
> > > fan_type=0 and then followed by info0= info1= the interpretation of
> > > those solely depend on fan_type. If the fan_type does not need both,
> > > then any interpretation skips what it doesn't need. If fan_type=1, then
> > > it follows what arg0= and arg1= is for that format. But make this pivot
> > > on fan_type and not actual names.
> > So I think there is some misunderstanding so let me maybe spell out in
> > detail how I see things so that we can get on the same page:
> >
> > It was a requirement from me (and probably Amir) that there is a generic
> > way to attach additional info to a response to fanotify permission event.
> > This is achieved by defining:
> >
> > struct fanotify_response_info_header {
> > __u8 type;
> > __u8 pad;
> > __u16 len;
> > };
> >
> > which is a generic header and kernel can based on 'len' field decide how
> > large the response structure is (to safely copy it from userspace) and
> > based on 'type' field it can decide who should be the recipient of this
> > extra information (or generally what to do with it). So any additional
> > info needs to start with this header.
> >
> > Then there is:
> >
> > struct fanotify_response_info_audit_rule {
> > struct fanotify_response_info_header hdr;
> > __u32 audit_rule;
> > };
> >
> > which properly starts with the header and hdr.type is expected to be
> > FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
> > FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
> > subsystem's responsibility. Fanotify code will just pass this as an opaque
> > blob to the audit subsystem.
> >
> > So if you know audit subsystem will also need some other field together
> > with 'audit_rule' now is a good time to add it and it doesn't have to be
> > useful for anybody else besides audit. If someone else will need other
> > information passed along with the response, he will append structure with
> > another header with different 'type' field. In principle, there can be
> > multiple structures appended to fanotify response like
> >
> > <hdr> <data> <hdr> <data> ...
> >
> > and fanotify subsystem will just pass them to different receivers based
> > on the type in 'hdr' field.
> >
> > Also if audit needs to pass even more information along with the respose,
> > we can define a new 'type' for it. But the 'type' space is not infinite so
> > I'd prefer this does not happen too often...
> >
> > I hope this clears out things a bit.
>
> Yes. Thank you.
>
> Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> unknown.
type? bitfield? My gut would say that "0" should be "unset"/"unknown",
but that is counterintuitive to the values represented.
Or "trust" with sub-fields "subj" and "obj"?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-09 14:38 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 14:38 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-09-09 10:22, Steve Grubb wrote:
> On Friday, September 9, 2022 7:09:44 AM EDT Jan Kara wrote:
> > Hello Steve!
> >
> > On Fri 09-09-22 00:03:53, Steve Grubb wrote:
> > > On Thursday, September 8, 2022 10:41:44 PM EDT Richard Guy Briggs wrote:
> > > > > I'm trying to abide by what was suggested by the fs-devel folks. I
> > > > > can
> > > > > live with it. But if you want to make something non-generic for all
> > > > > users of fanotify, call the new field "trusted". This would decern
> > > > > when
> > > > > a decision was made because the file was untrusted or access denied
> > > > > for
> > > > > another reason.
> > > >
> > > > So, "u32 trusted;" ? How would you like that formatted?
> > > > "fan_trust={0|1}"
> > >
> > > So how does this play out if there is another user? Do they want a num=
> > > and trust= if not, then the AUDIT_FANOTIFY record will have multiple
> > > formats which is not good. I'd rather suggest something generic that can
> > > be interpreted based on who's attached to fanotify. IOW we have a
> > > fan_type=0 and then followed by info0= info1= the interpretation of
> > > those solely depend on fan_type. If the fan_type does not need both,
> > > then any interpretation skips what it doesn't need. If fan_type=1, then
> > > it follows what arg0= and arg1= is for that format. But make this pivot
> > > on fan_type and not actual names.
> > So I think there is some misunderstanding so let me maybe spell out in
> > detail how I see things so that we can get on the same page:
> >
> > It was a requirement from me (and probably Amir) that there is a generic
> > way to attach additional info to a response to fanotify permission event.
> > This is achieved by defining:
> >
> > struct fanotify_response_info_header {
> > __u8 type;
> > __u8 pad;
> > __u16 len;
> > };
> >
> > which is a generic header and kernel can based on 'len' field decide how
> > large the response structure is (to safely copy it from userspace) and
> > based on 'type' field it can decide who should be the recipient of this
> > extra information (or generally what to do with it). So any additional
> > info needs to start with this header.
> >
> > Then there is:
> >
> > struct fanotify_response_info_audit_rule {
> > struct fanotify_response_info_header hdr;
> > __u32 audit_rule;
> > };
> >
> > which properly starts with the header and hdr.type is expected to be
> > FAN_RESPONSE_INFO_AUDIT_RULE. What happens after the header with type
> > FAN_RESPONSE_INFO_AUDIT_RULE until length hdr.len is fully within *audit*
> > subsystem's responsibility. Fanotify code will just pass this as an opaque
> > blob to the audit subsystem.
> >
> > So if you know audit subsystem will also need some other field together
> > with 'audit_rule' now is a good time to add it and it doesn't have to be
> > useful for anybody else besides audit. If someone else will need other
> > information passed along with the response, he will append structure with
> > another header with different 'type' field. In principle, there can be
> > multiple structures appended to fanotify response like
> >
> > <hdr> <data> <hdr> <data> ...
> >
> > and fanotify subsystem will just pass them to different receivers based
> > on the type in 'hdr' field.
> >
> > Also if audit needs to pass even more information along with the respose,
> > we can define a new 'type' for it. But the 'type' space is not infinite so
> > I'd prefer this does not happen too often...
> >
> > I hope this clears out things a bit.
>
> Yes. Thank you.
>
> Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> unknown.
type? bitfield? My gut would say that "0" should be "unset"/"unknown",
but that is counterintuitive to the values represented.
Or "trust" with sub-fields "subj" and "obj"?
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 14:38 ` Richard Guy Briggs
@ 2022-09-09 14:55 ` Steve Grubb
-1 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 14:55 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Paul Moore, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On Friday, September 9, 2022 10:38:46 AM EDT Richard Guy Briggs wrote:
> > Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> > unknown.
>
> type? bitfield? My gut would say that "0" should be "unset"/"unknown",
> but that is counterintuitive to the values represented.
>
> Or "trust" with sub-fields "subj" and "obj"?
No. just make them separate and u32. subj_trust and obj_trust - no sub fields.
If we have sub-fields, that probably means bit mapping and that wasn't wanted.
-Steve
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response
@ 2022-09-09 14:55 ` Steve Grubb
0 siblings, 0 replies; 91+ messages in thread
From: Steve Grubb @ 2022-09-09 14:55 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On Friday, September 9, 2022 10:38:46 AM EDT Richard Guy Briggs wrote:
> > Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> > unknown.
>
> type? bitfield? My gut would say that "0" should be "unset"/"unknown",
> but that is counterintuitive to the values represented.
>
> Or "trust" with sub-fields "subj" and "obj"?
No. just make them separate and u32. subj_trust and obj_trust - no sub fields.
If we have sub-fields, that probably means bit mapping and that wasn't wanted.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
2022-09-09 14:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
@ 2022-09-09 18:50 ` Richard Guy Briggs
-1 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 18:50 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Paul Moore, Linux-Audit Mailing List, LKML,
linux-fsdevel, Eric Paris, Amir Goldstein
On 2022-09-09 10:55, Steve Grubb wrote:
> On Friday, September 9, 2022 10:38:46 AM EDT Richard Guy Briggs wrote:
> > > Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> > > unknown.
> >
> > type? bitfield? My gut would say that "0" should be "unset"/"unknown",
> > but that is counterintuitive to the values represented.
> >
> > Or "trust" with sub-fields "subj" and "obj"?
>
> No. just make them separate and u32. subj_trust and obj_trust - no sub fields.
> If we have sub-fields, that probably means bit mapping and that wasn't wanted.
Ack.
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response
@ 2022-09-09 18:50 ` Richard Guy Briggs
0 siblings, 0 replies; 91+ messages in thread
From: Richard Guy Briggs @ 2022-09-09 18:50 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Amir Goldstein, LKML, Linux-Audit Mailing List,
linux-fsdevel, Eric Paris
On 2022-09-09 10:55, Steve Grubb wrote:
> On Friday, September 9, 2022 10:38:46 AM EDT Richard Guy Briggs wrote:
> > > Richard, add subj_trust and obj_trust. These can be 0|1|2 for no, yes,
> > > unknown.
> >
> > type? bitfield? My gut would say that "0" should be "unset"/"unknown",
> > but that is counterintuitive to the values represented.
> >
> > Or "trust" with sub-fields "subj" and "obj"?
>
> No. just make them separate and u32. subj_trust and obj_trust - no sub fields.
> If we have sub-fields, that probably means bit mapping and that wasn't wanted.
Ack.
> -Steve
- RGB
--
Richard Guy Briggs <rgb@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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2022-09-09 18:50 UTC | newest]
Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-09 17:22 [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 1/4] fanotify: Ensure consistent variable type for response Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 2/4] fanotify: define struct members to hold response decision context Richard Guy Briggs
2022-08-09 17:22 ` Richard Guy Briggs
2022-08-10 6:22 ` Amir Goldstein
2022-08-10 6:22 ` Amir Goldstein
2022-08-19 11:24 ` Jan Kara
2022-08-19 11:24 ` Jan Kara
2022-08-10 14:28 ` kernel test robot
2022-08-10 14:28 ` kernel test robot
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-12 0:23 ` Matthew Bobrowski
2022-08-12 0:23 ` Matthew Bobrowski
2022-08-19 11:16 ` Jan Kara
2022-08-19 11:16 ` Jan Kara
2022-08-19 11:13 ` Jan Kara
2022-08-19 11:13 ` Jan Kara
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 3/4] fanotify, audit: " Richard Guy Briggs
2022-08-10 20:32 ` [PATCH v4 3/4] fanotify,audit: " kernel test robot
2022-08-10 20:32 ` kernel test robot
2022-08-16 0:22 ` Paul Moore
2022-08-16 0:22 ` Paul Moore
2022-08-31 21:07 ` Richard Guy Briggs
2022-08-31 21:07 ` Richard Guy Briggs
2022-08-31 21:25 ` Steve Grubb
2022-08-31 21:25 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-08-31 22:19 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs
2022-08-31 22:19 ` Richard Guy Briggs
2022-08-31 23:55 ` Steve Grubb
2022-08-31 23:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-01 1:47 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore
2022-09-01 1:47 ` Paul Moore
2022-09-01 7:51 ` Jan Kara
2022-09-01 7:51 ` Jan Kara
2022-09-01 18:31 ` Paul Moore
2022-09-01 18:31 ` Paul Moore
2022-09-07 18:43 ` Richard Guy Briggs
2022-09-07 18:43 ` Richard Guy Briggs
2022-09-07 20:11 ` Steve Grubb
2022-09-07 20:11 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-07 20:23 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore
2022-09-07 20:23 ` Paul Moore
2022-09-08 21:14 ` Steve Grubb
2022-09-08 21:14 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-08 21:22 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore
2022-09-08 21:22 ` Paul Moore
2022-09-09 2:20 ` Steve Grubb
2022-09-09 2:20 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 2:41 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs
2022-09-09 2:41 ` Richard Guy Briggs
2022-09-09 3:25 ` Paul Moore
2022-09-09 3:25 ` Paul Moore
2022-09-09 4:03 ` Steve Grubb
2022-09-09 4:03 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 11:09 ` [PATCH v4 3/4] fanotify,audit: " Jan Kara
2022-09-09 11:09 ` Jan Kara
2022-09-09 14:22 ` Steve Grubb
2022-09-09 14:22 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 14:38 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs
2022-09-09 14:38 ` Richard Guy Briggs
2022-09-09 14:55 ` Steve Grubb
2022-09-09 14:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb
2022-09-09 18:50 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs
2022-09-09 18:50 ` Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string Richard Guy Briggs
2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
2022-08-10 19:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb
2022-08-10 19:15 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
2022-08-11 2:23 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs
2022-08-11 2:23 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
2022-08-15 21:15 ` Steve Grubb
2022-08-15 21:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb
2022-08-16 0:31 ` [PATCH v4 4/4] fanotify, audit: " Paul Moore
2022-08-16 0:31 ` [PATCH v4 4/4] fanotify,audit: " Paul Moore
2022-08-16 13:37 ` Steve Grubb
2022-08-16 13:37 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb
2022-08-19 21:42 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs
2022-08-19 21:42 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs
2022-08-10 5:21 ` [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Amir Goldstein
2022-08-10 5:21 ` Amir Goldstein
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.