> + newcont->owner = current;
> + refcount_set(&newcont->refcount, 1);
> + list_add_rcu(&newcont->list,
> &audit_contid_hash[h]);
> + } else {
> + rc = -ENOMEM;
> + goto conterror;
> + }
> + }
> + task->audit->cont = newcont;
> + audit_cont_put(oldcont);
> +conterror:
> + spin_unlock(&audit_contid_list_lock);
> + }
> task_unlock(task);
>
> if (!audit_enabled)
> diff --git a/kernel/audit.h b/kernel/audit.h
> index 16bd03b88e0d..e4a31aa92dfe 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -211,6 +211,14 @@ static inline int audit_hash_ino(u32 ino)
> return (ino & (AUDIT_INODE_BUCKETS-1));
> }
>
> +#define AUDIT_CONTID_BUCKETS 32
> +extern struct list_head audit_contid_hash[AUDIT_CONTID_BUCKETS];
> +
> +static inline int audit_hash_contid(u64 contid)
> +{
> + return (contid & (AUDIT_CONTID_BUCKETS-1));
> +}
> +
> /* Indicates that audit should log the full pathname. */
> #define AUDIT_NAME_FULL -1
>
--
paul moore
www.paul-moore.com
n CONFIG_AUDIT=n case
> - improve operations naming (paul)
> ---
> fs/namei.c | 8 ++--
> include/linux/audit.h | 5 +++--
> include/uapi/linux/audit.h | 1 +
> kernel/audit.c | 11 ++-
> 4 files changed, 16 insertions(+),
2 && S_ISFIFO(inode->i_mode)) ||
> (sysctl_protected_regular >= 2 && S_ISREG(inode->i_mode) {
> + const char *operation = S_ISFIFO(inode->i_mode) ?
> + "sticky_create_fifo" :
> + "sticky_create_regular";
> + audit_log_path_denied(AUDIT_ANOM_CREAT, operation);
This is a new record, so this is fine. Thanks for changing this.
--
paul moore
www.paul-moore.com
uffer *ab, char *key)
> { }
> -static inline void audit_log_link_denied(const char *string)
> +static inline void audit_log_path_denied(int type, const char *string);
> { }
I probably wouldn't make you respin just for this, but since you may
need to respin this anyway, you might as well fix the above.
--
paul moore
www.paul-moore.com
On Mon, Sep 30, 2019 at 2:29 PM Kees Cook wrote:
> On Mon, Sep 30, 2019 at 09:50:00AM -0400, Steve Grubb wrote:
> > On Thursday, September 26, 2019 11:31:32 AM EDT Paul Moore wrote:
> > > On Wed, Sep 25, 2019 at 5:02 PM Kees Cook wrote:
> > > >
On Tue, Sep 24, 2019 at 1:05 PM Paul Moore wrote:
> On Tue, Sep 24, 2019 at 9:50 AM Richard Guy Briggs wrote:
> > On 2019-09-23 23:01, Paul Moore wrote:
> > > On Mon, Sep 23, 2019 at 5:00 PM Richard Guy Briggs
> > > wrote:
> > > > On 2019-09-23 12:14, Pau
tions which audit was created to satisfy.
In some cases a printk() isn't sufficient.
Steve is probably the only one who really keeps track of the various
auditing requirements of the different security certifications; what
say you Steve on this issue with ANOM_CREAT records?
--
paul moore
www.paul-moore.com
The version of perltidy currently available in Travis CI via
Ubuntu 16.04 LTS doesn't produce the same output as the perltidy
shipped in more modern distros. This patchset addresses this by
installing perltidy from the upstream sources.
---
Paul Moore (2):
audit-testsuite: use ou
From: Paul Moore
Unfortunately the perltidy results differ between moden distros and the
current Travis CI environment. This patch attempts to address this by
using the current upstream perltidy in the Travis CI tests.
Signed-off-by: Paul Moore
---
.travis.yml | 10 +-
1 file
From: Paul Moore
Signed-off-by: Paul Moore
---
tests/exec_execve/test |2 +-
tests/exec_name/test |2 +-
tests/file_create/test |2 +-
tests/file_delete/test |2 +-
tests/file_rename/test
On Tue, Sep 24, 2019 at 9:50 AM Richard Guy Briggs wrote:
> On 2019-09-23 23:01, Paul Moore wrote:
> > On Mon, Sep 23, 2019 at 5:00 PM Richard Guy Briggs wrote:
> > > On 2019-09-23 12:14, Paul Moore wrote:
> > > > On Mon, Sep 23, 2019 at 11:50 AM Dave Jones
> &
On Tue, Sep 24, 2019 at 9:19 AM Steve Grubb wrote:
> On Monday, September 23, 2019 12:14:14 PM EDT Paul Moore wrote:
> > On Mon, Sep 23, 2019 at 11:50 AM Dave Jones
> wrote:
> > > I have some hosts that are constantly spewing audit messages like so:
> > >
> &g
On Mon, Sep 23, 2019 at 5:00 PM Richard Guy Briggs wrote:
> On 2019-09-23 12:14, Paul Moore wrote:
> > On Mon, Sep 23, 2019 at 11:50 AM Dave Jones wrote:
> > >
> > > I have some hosts that are constantly spewing audit messages like so:
> > >
> &g
x27;ll go with a weak "maybe" ;)
> On Mon, 2019-09-23 at 15:49 -0400, Dave Jones wrote:
> > On Mon, Sep 23, 2019 at 02:57:08PM -0400, Paul Moore wrote:
> > > On Mon, Sep 23, 2019 at 12:58 PM Dave Jones <
> > da...@codemonkey.org.uk> wrote:
> &
On Mon, Sep 23, 2019 at 12:58 PM Dave Jones wrote:
> On Mon, Sep 23, 2019 at 12:14:14PM -0400, Paul Moore wrote:
> > On Mon, Sep 23, 2019 at 11:50 AM Dave Jones
> wrote:
> > >
> > > I have some hosts that are constantly spewing audit messages like so:
> >
can be bizzare and I can't
say I'm up to date on all those - Steve Grubb should be able to
comment on that).
--
paul moore
www.paul-moore.com
On Wed, Sep 18, 2019 at 9:50 PM Li,Rongqing wrote:
> > -邮件原件-
> > 发件人: Paul Moore [mailto:p...@paul-moore.com]
> > 发送时间: 2019年9月18日 20:23
> > 收件人: Li,Rongqing
> > 抄送: Eric Paris ; linux-audit@redhat.com
> > 主题: Re: [PATCH][RFC] audit: set wait time
On Tue, Sep 17, 2019 at 9:07 PM Li,Rongqing wrote:
> > -邮件原件-
> > 发件人: Paul Moore [mailto:p...@paul-moore.com]
> > 发送时间: 2019年9月18日 3:17
> > 收件人: Li,Rongqing
> > 抄送: Eric Paris ; linux-audit@redhat.com
> > 主题: Re: [PATCH][RFC] audit: set wait time to z
A quick note in case anyone was wondering ... we don't have anything
queued up in audit/next for the v5.4 merge window, so no audit updates
this time around.
--
paul moore
www.paul-moore.com
On Mon, Sep 16, 2019 at 9:08 PM Li,Rongqing wrote:
> > -邮件原件-
> > 发件人: Paul Moore [mailto:p...@paul-moore.com]
> > 发送时间: 2019年9月17日 6:52
> > 收件人: Li,Rongqing
> > 抄送: Eric Paris ; linux-audit@redhat.com
> > 主题: Re: [PATCH][RFC] audit: set wait time to z
runtime (look at what Fedora does).
> > You might also want to investigate
> > what is generating some many audit records prior to starting the audit
> > daemon.
>
> It is /sbin/readahead-collector, in fact, we stop the auditd; We are doing a
> reboot test, which rebootin
}
>
> + if (audit_backlog_wait_time != audit_backlog_wait_time_master)
> + audit_backlog_wait_time = audit_backlog_wait_time_master;
> +
> ab = audit_buffer_alloc(ctx, gfp_mask, type);
> if (!ab) {
> audit_log_lost("out of memory in audit_log_start");
> --
> 2.16.2
>
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
have to change SELinux policy to enable this data
> collection. I should be able to change the audit configuration
> to get this if I want it.
The idea is that the LSM can request that the audit subsystem
selectively enable auditing (per-task, and hopefully per-record-type);
the audit policy c
On Tue, Aug 27, 2019 at 10:39 AM Paul Moore wrote:
> From: Paul Moore
>
> Updates include additional packages and instructions on changing
> /bin/sh from Dash to BASH.
>
> Signed-off-by: Paul Moore
> ---
> README.md | 11 +++
> 1 file changed, 11 insertio
From: Paul Moore
Updates include additional packages and instructions on changing
/bin/sh from Dash to BASH.
Signed-off-by: Paul Moore
---
README.md | 11 +++
1 file changed, 11 insertions(+)
diff --git a/README.md b/README.md
index bc20a21..0f6c861 100644
--- a/README.md
+++ b
On Thu, Aug 22, 2019 at 3:22 AM Chen Wandun wrote:
> On 2019/8/21 23:36, Paul Moore wrote:
> > On Wed, Aug 21, 2019 at 5:31 AM Chen Wandun wrote:
> >>
> >> Hi,
> >> Recently, I hit a use after delete in audit_filter_inodes,
> >
> > ...
> >
nce v3.10.0 was released. If you see the same problem on a modern
upstream kernel please let us know, we'll be happy to help.
--
paul moore
www.paul-moore.com
are a few things in dump_common_audit_data() that should
have been done differently, but unfortunately the audit records (and
IMHO the many stupid design decisions that went into them) are
effectively part of the kernel API and need to be treated with care.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
"file".
I'm not sure if any of this is going to be a good idea, but I think we
need to discuss it a bit before we start duplicating things in
lsm_audit.c.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
On Wed, Aug 14, 2019 at 5:08 PM Stephen Smalley wrote:
> On 8/14/19 3:59 PM, Paul Moore wrote:
> > On Tue, Aug 13, 2019 at 5:27 PM Richard Guy Briggs wrote:
> >> On 2019-08-13 11:01, Aaron Goidel wrote:
> >>> On 8/8/19 12:30 PM, Paul Moore wrote:
> >>&
On Tue, Aug 13, 2019 at 5:27 PM Richard Guy Briggs wrote:
> On 2019-08-13 11:01, Aaron Goidel wrote:
> > On 8/8/19 12:30 PM, Paul Moore wrote:
> > > On Thu, Aug 1, 2019 at 10:43 AM Aaron Goidel
> > > wrote:
> > > > From: Nicholas Franck
> > > >
al recommended practice when it comes to "sometimes" fields
in an audit record, is to always record them in the record, but use a
value of "?" when there is nothing relevant to record. For example,
when *not* recording inode information you would do something like the
following:
audit_log_format(ab, " dev=? ino=?");
> + }
> + }
> break;
> + }
> case LSM_AUDIT_DATA_PATH: {
> struct inode *inode;
>
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
apture information that is closely related to the syscall arguments
(e.g. we record PATH records for the open(2) syscall), we only do so
in some special cases.
My gut feeling is that you might be better off looking into some of
the kernel tracing tools, or even just something like strace/ptrace.
-
> do not appreciate what they are not seeing? Or perhaps they are not
> starting as many services early in the boot sequence and therefore
> getting that one?
As a gentle reminder, this is the *upstream* Linux audit mailing list;
discussion about distro specific issues, especially older distros with
"enterprise" support, are best done offline via that distro's support
mechanism :)
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
> struct audit_krule *b)
> return 1;
> break;
> case AUDIT_WATCH:
> + if (!a->watch)
> + break;
> if (strcmp(audit_watch_path(a->w
On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler wrote:
> On 7/22/2019 1:50 PM, James Morris wrote:
> > On Fri, 19 Jul 2019, Paul Moore wrote:
> >
> >>> We've never had to think about having general rules on
> >>> what security modules do before, beca
On Wed, Jul 17, 2019 at 7:02 PM Casey Schaufler wrote:
> On 7/17/2019 9:23 AM, Paul Moore wrote:
> > On Wed, Jul 17, 2019 at 11:49 AM Casey Schaufler
> > wrote:
> >> On 7/17/2019 5:14 AM, Paul Moore wrote:
> >>> On Tue, Jul 16, 2019 at 7:47 PM Casey Schaufle
On Wed, Jul 17, 2019 at 8:52 PM Richard Guy Briggs wrote:
> On 2019-07-16 19:30, Paul Moore wrote:
...
> > We can trust capable(CAP_AUDIT_CONTROL) for enforcing audit container
> > ID policy, we can not trust ns_capable(CAP_AUDIT_CONTROL).
>
> Ok. So does a process in a no
On Wed, Jul 17, 2019 at 11:49 AM Casey Schaufler wrote:
> On 7/17/2019 5:14 AM, Paul Moore wrote:
> > On Tue, Jul 16, 2019 at 7:47 PM Casey Schaufler
> > wrote:
> >> On 7/16/2019 4:13 PM, Paul Moore wrote:
> >>> On Tue, Jul 16, 2019 at 6:18 PM Casey Schaufle
On Wed, Jul 17, 2019 at 12:36 AM James Morris wrote:
> On Tue, 16 Jul 2019, Paul Moore wrote:
>
> > The subj_X approach is still backwards compatible, the difference is
> > that old versions of the tools get a "?" for the LSM creds which is a
> > rather s
On Tue, Jul 16, 2019 at 7:47 PM Casey Schaufler wrote:
> On 7/16/2019 4:13 PM, Paul Moore wrote:
> > On Tue, Jul 16, 2019 at 6:18 PM Casey Schaufler
> > wrote:
> >> It sounds as if some variant of the Hideous format:
> >>
> >> subj=selinu
On Tue, Jul 16, 2019 at 6:03 PM Richard Guy Briggs wrote:
> On 2019-07-15 17:04, Paul Moore wrote:
> > On Mon, Jul 8, 2019 at 2:06 PM Richard Guy Briggs wrote:
...
> > > If we can't trust ns_capable() then why are we passing on
> > > CAP_AUDIT_CONTROL? It is be
t Steve's searchability requirements, but with significant
> parsing performance penalties.
I think "hideous format" sums it up nicely. Whatever we choose here
we are likely going to be stuck with for some time and I'm near to
100% that multiplexing the labels onto a
On Tue, Jul 16, 2019 at 5:46 PM Steve Grubb wrote:
> On Tuesday, July 16, 2019 5:25:21 PM EDT Paul Moore wrote:
...
> > Agreed. While I'm not going to be on a specific Linux release, I do
> > believe that at some point in the future the LSM stacking work is
> > go
On Tue, Jul 16, 2019 at 3:38 PM Richard Guy Briggs wrote:
> On 2019-07-15 16:38, Paul Moore wrote:
> > On Mon, Jul 8, 2019 at 1:51 PM Richard Guy Briggs wrote:
> > > On 2019-05-29 11:29, Paul Moore wrote:
> >
> > ...
> >
> > > > The idea is tha
On Tue, Jul 16, 2019 at 2:41 PM Casey Schaufler wrote:
> On 7/16/2019 11:06 AM, Steve Grubb wrote:
> > On Tuesday, July 16, 2019 1:43:18 PM EDT Paul Moore wrote:
> >> On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler
> > wrote:
> >>> On 7/16/2019 10:12 AM, Pau
On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler wrote:
> On 7/16/2019 10:12 AM, Paul Moore wrote:
> > On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb wrote:
> >> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote:
> >>> On Mon, Jul 15, 2019 at 3:37 PM Casey Scha
On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb wrote:
> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote:
> > On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler
> wrote:
> > > On 7/15/2019 12:04 PM, Richard Guy Briggs wrote:
> > > > On 2019-07-13 11:08, Steve G
On Tue, Jul 16, 2019 at 11:37 AM Richard Guy Briggs wrote:
> On 2019-07-15 17:09, Paul Moore wrote:
> > On Mon, Jul 8, 2019 at 2:12 PM Richard Guy Briggs wrote:
> > > On 2019-05-30 19:26, Paul Moore wrote:
> >
> > ...
> >
> > > > I like the
but still
want to include subject and/or object information. Unfortunately we
are stuck with some tough limitations given the current audit record
format and Steve's audit userspace tools; I can toss out some
suggestions but it would be nice to hear what Steve's tools would
support with respect to LSM subject/object value formats. Steve, are
these values interpreted at all by your tools, or are the opaque
values?
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
On Mon, Jul 8, 2019 at 2:12 PM Richard Guy Briggs wrote:
> On 2019-05-30 19:26, Paul Moore wrote:
...
> > I like the creativity, but I worry that at some point these
> > limitations are going to be raised (limits have a funny way of doing
> > that over time) and we will
On Mon, Jul 8, 2019 at 2:06 PM Richard Guy Briggs wrote:
> On 2019-05-30 15:29, Paul Moore wrote:
...
> > [REMINDER: It is an "*audit* container ID" and not a general
> > "container ID" ;) Smiley aside, I'm not kidding about that part.]
> >
On Mon, Jul 8, 2019 at 1:51 PM Richard Guy Briggs wrote:
> On 2019-05-29 11:29, Paul Moore wrote:
...
> > The idea is that only container orchestrators should be able to
> > set/modify the audit container ID, and since setting the audit
> > container ID can have a sign
On July 8, 2019 8:12:56 PM Richard Guy Briggs wrote:
> On 2019-05-30 19:26, Paul Moore wrote:
>> On Thu, May 30, 2019 at 5:29 PM Tycho Andersen wrote:
>>> On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
>>>>
>>>>
>>>> [REMIN
)
audit/stable-5.3 PR 20190702
Paul Moore (1):
audit: remove the BUG() calls in the audit rule comparison functions
Richard Guy Briggs (4):
audit: deliver signal_info regarless of syscall
audit: re
> Signed-off-by: Richard Guy Briggs
> ---
> security/selinux/ss/services.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
Generally rc6/rc7 is a bit late for things, but this is pretty
straightforward so I think it should be safe. Merged into
selinux/next.
--
paul moore
www.paul-moore.com
On Mon, Jun 24, 2019 at 10:15 PM John Johansen
wrote:
> On 6/24/19 6:46 PM, Paul Moore wrote:
> > On Mon, Jun 24, 2019 at 9:01 PM Casey Schaufler
> > wrote:
> >> On 6/24/2019 2:33 PM, John Johansen wrote:
> >>> On 6/21/19 11:52 AM, Casey Schaufler wrote:
&
t_log_format(ab, " osid=%u", osid);
> > I am not comfortable just dropping this I would think logging all secids is
> > the
> > correct action here.
> >
> >
> >> +if (security_secid_to_secctx(olsm, &lsmcxt))
> >> *call_panic = 1;
> >> -} else {
> >> +else {
> >> audit_log_format(ab, " obj=%s",
> >> lsmcxt.context);
> >> security_release_secctx(&lsmcxt);
> >> }
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
he cover letter and it sounds like Richard is working up some
ideas now, let's wait to see what that looks like."
... and that is where we are at. I'm looking forward to seeing
Richard's next patchset.
> On Friday, May 31, 2019 8:44:45 AM EDT Paul Moore wrote:
> > On
/* no need to record the NUL with untrusted strings */
audit_log_n_untrustedstring(n, nlen - 1);
audit_log_format(...);
audit_log_end(...);
> I'm not sure if it
> is worth changing this patch / consolidating the style across all
> places that do this / creating a helper function...
If anyone is going to look into that, it should be done in a separate patch.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
ontext() and security_sid_mls_copy() cases
below it would appear that the labels can be considered "trusted",
even if they are invalid. I understand your concern about logging
consistency with the "invalid_context" field, but without some further
discussion it is hard to accept this patch as-is.
--
paul moore
www.paul-moore.com
On Wed, Jun 12, 2019 at 3:37 AM Ondrej Mosnacek wrote:
> On Wed, Jun 12, 2019 at 12:56 AM Paul Moore wrote:
> > On Tue, Jun 11, 2019 at 4:07 AM Ondrej Mosnacek wrote:
> > > These strings may come from untrusted sources (e.g. file xattrs) so they
> > >
t;, scontext);
> + if (scontext_len && scontext[scontext_len - 1] == '\0')
> + scontext_len--;
> + audit_log_format(ab, " trawcon=");
> + audit_log_n_untrustedstring(ab, scontext, scontext_len);
> kfree(scontext);
> }
> }
> --
> 2.20.1
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
this will block the container id for years.
It's ready when it's ready.
> On 6/3/19 6:01 PM, Paul Moore wrote:
> > On Fri, May 31, 2019 at 1:54 PM Richard Guy Briggs wrote:
> >> Remove the BUG() call since we will never have an invalid op value as
> >> audit_
((left & right) == right);
> default:
> - BUG();
> return 0;
> }
> }
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
On Thu, May 30, 2019 at 8:21 PM Richard Guy Briggs wrote:
> On 2019-05-30 19:26, Paul Moore wrote:
> > On Thu, May 30, 2019 at 5:29 PM Tycho Andersen wrote:
> > > On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
> > > >
> > > > [REMINDER:
On Thu, May 30, 2019 at 5:29 PM Tycho Andersen wrote:
> On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
> >
> > [REMINDER: It is an "*audit* container ID" and not a general
> > "container ID" ;) Smiley aside, I'm not kidding about that pa
On Thu, May 30, 2019 at 4:37 PM Richard Guy Briggs wrote:
> On 2019-05-30 10:34, Paul Moore wrote:
> > On Thu, May 30, 2019 at 10:20 AM Richard Guy Briggs wrote:
> > >
> > > On 2019-05-29 18:16, Paul Moore wrote:
> > > > On Mon, Apr 8, 2019 at 11:4
On Thu, May 30, 2019 at 3:34 PM Richard Guy Briggs wrote:
> On 2019-05-30 12:55, Paul Moore wrote:
> > The audit_data_to_entry() function ensures that the operator is valid
> > so we can get rid of these BUG() calls. We keep the "return 0" just
> > so the syst
On Thu, May 30, 2019 at 1:09 PM Serge E. Hallyn wrote:
> On Wed, May 29, 2019 at 06:39:48PM -0400, Paul Moore wrote:
> > On Wed, May 29, 2019 at 6:28 PM Tycho Andersen wrote:
> > > On Wed, May 29, 2019 at 12:03:58PM -0400, Paul Moore wrote:
> > > > On Wed, May 29, 2
The audit_data_to_entry() function ensures that the operator is valid
so we can get rid of these BUG() calls. We keep the "return 0" just
so the system behaves in a sane-ish manner should something go
horribly wrong.
Signed-off-by: Paul Moore
---
kernel/auditfilter.c |3 ---
1 fi
On Thu, May 30, 2019 at 10:20 AM Richard Guy Briggs wrote:
>
> On 2019-05-29 18:16, Paul Moore wrote:
> > On Mon, Apr 8, 2019 at 11:41 PM Richard Guy Briggs wrote:
> > >
> > > Implement audit container identifier filtering using the AUDIT_CONTID
> > > f
On Thu, May 30, 2019 at 10:09 AM Richard Guy Briggs wrote:
>
> On 2019-05-30 15:08, Ondrej Mosnacek wrote:
> > On Thu, May 30, 2019 at 12:16 AM Paul Moore wrote:
> > > On Mon, Apr 8, 2019 at 11:40 PM Richard Guy Briggs
> > > wrote:
> > > >
> >
On Thu, May 30, 2019 at 10:16 AM Richard Guy Briggs wrote:
>
> On 2019-05-29 18:17, Paul Moore wrote:
> > On Mon, Apr 8, 2019 at 11:41 PM Richard Guy Briggs wrote:
> > >
> > > Audit events could happen in a network namespace outside of a task
> > > conte
On Thu, May 30, 2019 at 9:08 AM Steve Grubb wrote:
> On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote:
> > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote:
> > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman
> wrote:
> > > > On Mon, Apr 08, 2019 at 11:
On Wed, May 29, 2019 at 6:28 PM Tycho Andersen wrote:
> On Wed, May 29, 2019 at 12:03:58PM -0400, Paul Moore wrote:
> > On Wed, May 29, 2019 at 11:34 AM Tycho Andersen wrote:
> > >
> > > On Wed, May 29, 2019 at 11:29:05AM -0400, Paul Moore wrote:
> > > >
On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote:
> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote:
> > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote:
> > > Implement kernel audit container identifier.
> >
> > I'm sorry, I've lost t
GFP_ATOMIC);
> + if (cont) {
> + INIT_LIST_HEAD(&cont->list);
I thought you were going to get rid of this INIT_LIST_HEAD() call?
> + cont->id = contid;
> + refcount_set(&cont->refcount, 1);
> + list_add_rcu(&cont->list, contid_list);
> + }
> +out:
> + spin_unlock(&aunet->contid_list_lock);
> +}
--
paul moore
www.paul-moore.com
is time. It appears as though we will never have an invalid op
value as audit_data_to_entry()/audit_to_op() ensure that the op value
is a a known good value. Removing the BUG() from all the audit
comparators is a separate issue, but I think it would be good to
remove it from this newly added comparator; keeping it so that we
return "0" in the default case seems reasoanble.
> + return 0;
> + }
> +}
--
paul moore
www.paul-moore.com
cumentation/core-api/printk-formats.rst the recommendation for
u64 is %llu (or %llx, if you want hex). Looking quickly through the
printk code this appears to still be correct. I suggest we get rid of
the cast (like it was in v5).
> + audit_log_end(ab);
> +}
> +EXPORT_SYMBOL(audit_log_contid);
--
paul moore
www.paul-moore.com
On Wed, May 29, 2019 at 11:34 AM Tycho Andersen wrote:
>
> On Wed, May 29, 2019 at 11:29:05AM -0400, Paul Moore wrote:
> > On Wed, May 29, 2019 at 10:57 AM Tycho Andersen wrote:
> > >
> > > On Mon, Apr 08, 2019 at 11:39:09PM -0400, Richard Guy Briggs wrote:
> &
anted
CAP_AUDIT_CONTROL (which everyone to date seems to agree is a workable
compromise). We did consider allowing for a chain of nested audit
container IDs, but the implications of doing so are significant
(implementation mess, runtime cost, etc.) so we are leaving that out
of this effort.
>From a practical perspective, un-setting the audit container ID is
pretty much the same as changing it from one set value to another so
most of the above applies to that case as well.
--
paul moore
www.paul-moore.com
On Wed, May 29, 2019 at 10:07 AM Daniel Walsh wrote:
> On 5/29/19 9:17 AM, Paul Moore wrote:
> > On Wed, May 29, 2019 at 8:03 AM Daniel Walsh wrote:
> >> On 5/28/19 8:43 PM, Richard Guy Briggs wrote:
> >>> On 2019-05-28 19:00, Steve Grubb wrote:
> >>>
On Wed, May 29, 2019 at 8:03 AM Daniel Walsh wrote:
>
> On 5/28/19 8:43 PM, Richard Guy Briggs wrote:
> > On 2019-05-28 19:00, Steve Grubb wrote:
> >> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote:
> >>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh
On Tue, May 28, 2019 at 8:44 PM Richard Guy Briggs wrote:
> On 2019-05-28 19:00, Steve Grubb wrote:
> > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote:
> > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote:
...
> > > > Mrunal Patel (maintainer of CRI-
On Tue, May 28, 2019 at 6:22 PM Richard Guy Briggs wrote:
> On 2019-05-28 18:00, Paul Moore wrote:
> > On Wed, May 22, 2019 at 5:52 PM Richard Guy Briggs wrote:
> > >
> > > The field operator is ignored on several string fields. WATCH, DIR,
> > > PERM and FIL
On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote:
>
> On 4/22/19 9:49 AM, Paul Moore wrote:
> > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote:
> >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote:
> >>> Implement kernel audit container
result = audit_match_filetype(ctx, f->val);
> + if (f->op == Audit_not_equal)
> + result = !result;
> break;
> case AUDIT_FIELD_COMPARE:
> result = audit_field_compare(tsk, cred, f, ctx, name);
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
hak73 v2
> - check for valid range of saddr_fam value
> v3:
> - eliminate AF_UNSPEC check
>
> include/uapi/linux/audit.h | 1 +
> kernel/auditfilter.c | 5 +++++
> kernel/auditsc.c | 5 +
> 3 files changed, 11 insertions(+)
Merged into audit/next.
--
p
> +++-
> 1 file changed, 34 insertions(+), 22 deletions(-)
Merged into audit/next, thanks.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
you know in a
> > generic way based on any given syscall that one parameter is a file
> > descriptor
> > that can be cross referenced?
>
> This is even Al Viro territory...
I'm sure Al would have some better commentary on this than me, but to
do this properly would likely involve caching the full path used by
the various open() syscalls for the life of the given fd and then
doing some rather painful string comparisons on each file i/o syscall
- no thank you ;)
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
stly cosmetic in nature where the audit_filter_rules()
changes actually affect the behavior of the code and there is no
strong connection between the two changes. It seems like we would be
better off if you split the changes into two patches.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
; kernel/signal.c | 2 +-
> 5 files changed, 46 insertions(+), 19 deletions(-)
Merged into audit/next, thanks.
--
paul moore
www.paul-moore.com
On Fri, May 10, 2019 at 12:16 PM Richard Guy Briggs wrote:
> On 2019-05-10 11:28, Paul Moore wrote:
> > On Thu, May 9, 2019 at 8:02 PM Richard Guy Briggs wrote:
> > >
> > > Provide a method to filter out sockaddr and bind calls by network
> > > address f
case AUDIT_SADDR_FAM:
> + if (ctx->sockaddr)
> + result =
> audit_comparator(ctx->sockaddr->ss_family,
> + f->op, f->val);
> + break;
> case AUDIT_SUBJ_USER:
> case AUDIT_SUBJ_ROLE:
> case AUDIT_SUBJ_TYPE:
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
On Wed, May 8, 2019 at 9:52 PM Richard Guy Briggs wrote:
> On 2019-05-08 18:05, Paul Moore wrote:
> > On Wed, May 8, 2019 at 12:46 PM Richard Guy Briggs wrote:
> > >
> > > Provide a method to filter out sockaddr and bind calls by network
> > > address f
result =
> audit_comparator(ctx->sockaddr->ss_family,
> + f->op, f->val);
> + break;
> case AUDIT_SUBJ_USER:
> case AUDIT_SUBJ_ROLE:
> case AUDIT_SUBJ_TYPE:
> --
> 1.8.3.1
>
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
/integrity/evm/evm_secfs.c| 10 +--
43 files changed, 331 insertions(+), 107 deletions(-)
create mode 100644 arch/m68k/include/asm/syscall.h
create mode 100644 arch/unicore32/include/asm/syscall.h
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://ww
On Tue, Apr 30, 2019 at 1:01 PM Richard Guy Briggs wrote:
> On 2019-04-27 10:09, Paul Moore wrote:
> > On Fri, Apr 26, 2019 at 1:00 PM Richard Guy Briggs wrote:
...
> > Beyond that, looking at the patch below it seems like there is an
> > obvious omission regarding v
result =
> audit_comparator(ctx->sockaddr->ss_family,
> + f->op, f->val);
> + break;
> case AUDIT_SUBJ_USER:
> case AUDIT_SUBJ_ROLE:
> case AUDIT_SUBJ_TYPE:
> --
> 1.8.3.1
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
901 - 1000 of 2305 matches
Mail list logo
