Re: audit library license
Hello,
On Wednesday, February 1, 2023 1:00:37 AM EST 布施 博明 wrote:
> Thank you for the comment.
> I also find following commit.
> -
> https://github.com/linux-audit/audit-userspace/commit/e63a8b16281701510164
> 70075396e3697dd57a9b
>
> BTW, I found another license question.
>
> The libauparse.so are created following source codes.
>
> In 'auparse/Makefile.am'
>
> AM_CPPFLAGS = -I. -I${top_srcdir} -I${top_srcdir}/src -I${top_srcdir}/lib
> -I${top_srcdir}/common
>
> libauparse_la_SOURCES = lru.c interpret.c nvlist.c ellist.c \
> auparse.c auditd-config.c message.c data_buf.c \
> auparse-defs.h auparse-idata.h data_buf.h \
> nvlist.h auparse.h ellist.h \
> internal.h lru.h rnode.h interpret.h\
> private.h expression.c expression.h tty_named_keys.h\
> normalize.c normalize-llist.c normalize-llist.h \
> normalize-internal.h normalize_obj_kind_map.h \
> normalize_record_map.h normalize_syscall_map.h
>
> We can find following line in internal.h
>
> #include "auditd-config.h"
>
> I can find src/auditd-config.h file which is GPLv2.
>
> The "src/auditd-config.h" should be also LGPLv2.1
That file is also mislabeled. It is now corrected. Thanks for the review.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE
On Wed, Feb 1, 2023 at 3:34 PM Richard Guy Briggs wrote:
>
> fadvise and madvise both provide hints for caching or access pattern for
> file and memory respectively. Skip them.
You forgot to update the first sentence in the commit description :/
I'm still looking for some type of statement that you've done some
homework on the IORING_OP_MADVISE case to ensure that it doesn't end
up calling into the LSM, see my previous emails on this. I need more
than "Steve told me to do this".
I basically just want to see that some care and thought has gone into
this patch to verify it is correct and good.
> Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to
> io_uring")
> Signed-off-by: Richard Guy Briggs
> ---
> changelog
> v2:
> - drop *GETXATTR patch
> - drop FADVISE hunk
>
> io_uring/opdef.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/io_uring/opdef.c b/io_uring/opdef.c
> index 3aa0d65c50e3..d3f36c633ceb 100644
> --- a/io_uring/opdef.c
> +++ b/io_uring/opdef.c
> @@ -312,6 +312,7 @@ const struct io_op_def io_op_defs[] = {
> .issue = io_fadvise,
> },
> [IORING_OP_MADVISE] = {
> + .audit_skip = 1,
> .name = "MADVISE",
> .prep = io_madvise_prep,
> .issue = io_madvise,
> --
> 2.27.0
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
[PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE
fadvise and madvise both provide hints for caching or access pattern for
file and memory respectively. Skip them.
Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to
io_uring")
Signed-off-by: Richard Guy Briggs
---
changelog
v2:
- drop *GETXATTR patch
- drop FADVISE hunk
io_uring/opdef.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c
index 3aa0d65c50e3..d3f36c633ceb 100644
--- a/io_uring/opdef.c
+++ b/io_uring/opdef.c
@@ -312,6 +312,7 @@ const struct io_op_def io_op_defs[] = {
.issue = io_fadvise,
},
[IORING_OP_MADVISE] = {
+ .audit_skip = 1,
.name = "MADVISE",
.prep = io_madvise_prep,
.issue = io_madvise,
--
2.27.0
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 05/16] ipe: add userspace interface
On Tue, Jan 31, 2023 at 11:49:44AM +0100, Roberto Sassu wrote:
> On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:
> > From: Deven Bowers
> > +
> > +/**
> > + * new_policy - Write handler for the securityfs node, "ipe/new_policy".
> > + * @f: Supplies a file structure representing the securityfs node.
> > + * @data: Suppleis a buffer passed to the write syscall.
>
> Typo: Suppleis.
>
Thanks for spotting the typos!
> > + * @len: Supplies the length of @data.
> > + * @offset: unused.
> > + *
> > + * Return:
> > + * * >0- Success, Length of buffer written
> > + * * <0- Error
> > + */
> > +static ssize_t new_policy(struct file *f, const char __user *data,
> > + size_t len, loff_t *offset)
> > +{
> > + int rc = 0;
> > + char *copy = NULL;
> > + struct ipe_policy *p = NULL;
> > +
> > + if (!file_ns_capable(f, _user_ns, CAP_MAC_ADMIN))
> > + return -EPERM;
> > +
> > + copy = memdup_user_nul(data, len);
> > + if (IS_ERR(copy)) {
> > + rc = PTR_ERR(copy);
> > + goto err;
> > + }
> > +
> > + p = ipe_new_policy(NULL, 0, copy, len);
> > + if (IS_ERR(p)) {
> > + rc = PTR_ERR(p);
> > + goto err;
> > + }
> > +
> > + rc = ipe_new_policyfs_node(p);
> > + if (rc)
> > + goto err;
>
> Uhm, don't you need to do cleanup of allocated memory or revert the
> actions of ipe_new_policy()?
>
Yes that should be cleaned up but should be done in ipe_new_policy instead,
will add a ipe_free_policy call at the end. Thanks for pointing that out.
>
> I would like more to see all the functions managing the policy
> together. If the patch is too long, you could further split by adding
> the helpers (that don't directly deal with the policy) in a separate
> patch.
>
> Here you would simply instantiate dirs/files in securityfs and call the
> existing functions previously introduced.
>
> Roberto
>
I will try to split them in the next version. Thanks for the suggestion.
-Fan
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 00/16] Integrity Policy Enforcement LSM (IPE)
On Tue, Jan 31, 2023 at 03:22:05PM +0100, Roberto Sassu wrote: > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > > IPE has two known gaps: > > > > 1. IPE cannot verify the integrity of anonymous executable memory, such as > > the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd > > code. > > Unfortunately, as this is dynamically generated code, there is no way > > for IPE to ensure the integrity of this code to form a trust basis. In all > > cases, the return result for these operations will be whatever the admin > > configures the DEFAULT action for "EXECUTE". > > I think it would be useful to handle special cases, for example you > could allow a process that created a file with memfd to use it, at the > condition that nobody else writes it. > > This would be required during the boot, otherwise services could fail > to start (depending on the policy). > Thanks for the suggestion. I agree with your opinion and I think supporting memfd is possible but restricting read/write needs more hooks. We would like to avoid adding more complexity to this initial posting as necessary. We will consider this as a future work and will post follow-on patches in the future. -Fan > > 2. IPE cannot verify the integrity of interpreted languages' programs when > > these scripts invoked via `` ``. This is because the > > way interpreters execute these files, the scripts themselves are not > > evaluated as executable code through one of IPE's hooks. Interpreters > > can be enlightened to the usage of IPE by trying to mmap a file into > > executable memory (+X), after opening the file and responding to the > > error code appropriately. This also applies to included files, or high > > value files, such as configuration files of critical system components. > > Ok, it is a well known issue. Hopefully, it will be fixed soon. > > Roberto > -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH v9 09/16] block|security: add LSM blob to block_device
On Tue, Jan 31, 2023 at 12:53:59AM -0800, Christoph Hellwig wrote: > On Mon, Jan 30, 2023 at 02:57:24PM -0800, Fan Wu wrote: > > From: Deven Bowers > > > > block_device structures can have valuable security properties, > > based on how they are created, and what subsystem manages them. > > That's a lot of cloudy talk but no real explanation. Sorry for being too general here. Currently the only use target of this hook is dm-verity. We use the newly added security hook to save the dm-verity roothash and signature to the new bdev security blob during the bdev creation time, so LSMs can leverage this information to protect the system. I will add this example in the next version. -Fan -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
