-
Notifications
You must be signed in to change notification settings - Fork 444
add mknod lsm hooks #970
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add mknod lsm hooks #970
Conversation
tracee-ebpf/tracee/argprinters.go
Outdated
@@ -43,3 +43,37 @@ func PrintAlert(alert alert) string { | |||
|
|||
return res | |||
} | |||
|
|||
func ParseMknodMode(mode uint16) string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more appropriate to put this functino in libbpfgo helpers (https://github.com/aquasecurity/libbpfgo/blob/main/helpers/argumentParsers.go) instead of here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
opened a PR in libbpgo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, why not using the ParseInodeMode() already defined in the helpers pacakge of libbpfgo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ParseInodeMode is not suitable because in this case the mode is different format.
the way to parse the mode in this case is like the kernel does it here:
https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L3711
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this a different format? This is mode_t, and the values are the same
return -1; | ||
} | ||
|
||
struct dentry* dentry = (struct dentry*)PT_REGS_PARM2(ctx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we care about the first argument? It tells us the directory on which this dentry is created
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we don't care for this argument because the second argument is the full path - it contains the directory path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I ask why prefer security_path_mknod to security_inode_mknod?
security_path_mknod provide struct path argument which can get absolute file path with mounted file system (e.g., /mount_point/a/b/c), while security_inode_mknod only provide struct dentry/inode argument which is not aware of mounted file system and can only get path relative to mount point of filesystem (e.g., /a/b/c).
And I think this is a general question for all security_inode_* lsm hooks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
security_path_mknod (and all other path lsm hooks) are enabled by CONFIG_SECURITY_PATH which is not available on all distros: https://elixir.bootlin.com/linux/v5.14.8/source/include/linux/security.h#L1760
tracee-ebpf/tracee/tracee.bpf.c
Outdated
return -1; | ||
} | ||
save_str_to_buf(submit_p, (void *)&string_p->buf[*off], DEC_ARG(0, *tags)); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra line
No description provided.