boot parameter question

boot parameter question

[Lenny Bruzenak]

[-- Attachment #1.1: Type: text/plain, Size: 1484 bytes --]

I'm having trouble getting my "audit_backlog_limit" boot parameter
accepted.

I have the following 2 audit parameters on my boot line:

audit=1

audit_backlog_limit=8192

My /proc/cmdline shows them both once booted up.

But I'm not getting the audit_backlog_limit applied to the kernel audit
startup. I have a auditctl -b 8192 that runs from the audit.rules, and
the resulting CONFIG_change event shows "...audit_backlog_limit=8192,
old=64...".

After startup I run:

# auditctl -s

and see that I've lost 93 events.


Looking at the kernel code, I see that if the "audit=1" value is set, it
should print:

"enabled (after initialization)" , which I see in both dmesg and
/var/log/messages,

The second one (audit_backlog_limit=8192) should output IIUC:

"audit_backlog_limit: "  , which I don't see anywhere.

It's as if the parameter is being ignored. I've tried moving it to a
different spot so it isn't the last on the line, etc. Nothing.

I stumbled on this because I'm not seeing the "SYSTEM_BOOT" events
anymore; I suspect they are in the missing ones.

Pretty sure I don't have a typo; I've put it into the grub config and
run the grub2-mkconfig -o /boot/grub2/grub.cfg and booted from that.
Again, the parameter is there in /proc/cmdline but doesn't seem to be
accepted. No warnings about it either AFAICT.

RHEL7.6, kernel 3.10.0-957

Don't think the audit userspace version makes much difference, but it is
2.8.5.

Thanks in advance,

LCB

-- 
Lenny Bruzenak
MagitekLTD


[-- Attachment #1.2: Type: text/html, Size: 2156 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: boot parameter question

[Richard Guy Briggs]

On 2019-07-25 19:52, Lenny Bruzenak wrote:
> I'm having trouble getting my "audit_backlog_limit" boot parameter
> accepted.
> 
> I have the following 2 audit parameters on my boot line:
> 
> audit=1
> 
> audit_backlog_limit=8192
> 
> My /proc/cmdline shows them both once booted up.
> 
> But I'm not getting the audit_backlog_limit applied to the kernel audit
> startup. I have a auditctl -b 8192 that runs from the audit.rules, and
> the resulting CONFIG_change event shows "...audit_backlog_limit=8192,
> old=64...".
> 
> After startup I run:
> 
> # auditctl -s
> 
> and see that I've lost 93 events.
> 
> 
> Looking at the kernel code, I see that if the "audit=1" value is set, it
> should print:
> 
> "enabled (after initialization)" , which I see in both dmesg and
> /var/log/messages,
> 
> The second one (audit_backlog_limit=8192) should output IIUC:
> 
> "audit_backlog_limit: "  , which I don't see anywhere.
> 
> It's as if the parameter is being ignored. I've tried moving it to a
> different spot so it isn't the last on the line, etc. Nothing.

It is being ignored because that kernel command line extension to the
original feature was never backported to RHEL7.

In hindsight, that would have been pretty useful without causing much
risk.  Normally feature backport is driven by customer demand.  There
was a bit of pushback when it was first introduced upstream, but this is
exactly the scenario I envisioned where it would be most useful.  It is
possible to compile your own kernel and change the default value, but
that's obviously a hurdle for most.

> I stumbled on this because I'm not seeing the "SYSTEM_BOOT" events
> anymore; I suspect they are in the missing ones.
> 
> Pretty sure I don't have a typo; I've put it into the grub config and
> run the grub2-mkconfig -o /boot/grub2/grub.cfg and booted from that.
> Again, the parameter is there in /proc/cmdline but doesn't seem to be
> accepted. No warnings about it either AFAICT.
> 
> RHEL7.6, kernel 3.10.0-957
> 
> Don't think the audit userspace version makes much difference, but it is
> 2.8.5.
> 
> Thanks in advance,
> 
> LCB
> 
> -- 
> Lenny Bruzenak

- 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

Re: boot parameter question

[Lenny Bruzenak]

On 7/29/19 4:32 PM, Richard Guy Briggs wrote:

> It is being ignored because that kernel command line extension to the
> original feature was never backported to RHEL7.

That would definitely do it.

>
> In hindsight, that would have been pretty useful without causing much
> risk.  Normally feature backport is driven by customer demand.  There
> was a bit of pushback when it was first introduced upstream, but this is
> exactly the scenario I envisioned where it would be most useful.  It is
> possible to compile your own kernel and change the default value, but
> that's obviously a hurdle for most.

It would definitely have been useful, some might say even necessary,
given the audit event startup noise occurring with systemd.

Wow. Thanks Richard, I appreciate the answer on this.

LCB

-- 
Lenny Bruzenak
MagitekLTD

Re: boot parameter question

[Richard Guy Briggs]

On 2019-07-30 15:06, Lenny Bruzenak wrote:
> On 7/29/19 4:32 PM, Richard Guy Briggs wrote:
> > It is being ignored because that kernel command line extension to the
> > original feature was never backported to RHEL7.
> 
> That would definitely do it.
> 
> > In hindsight, that would have been pretty useful without causing much
> > risk.  Normally feature backport is driven by customer demand.  There
> > was a bit of pushback when it was first introduced upstream, but this is
> > exactly the scenario I envisioned where it would be most useful.  It is
> > possible to compile your own kernel and change the default value, but
> > that's obviously a hurdle for most.
> 
> It would definitely have been useful, some might say even necessary,
> given the audit event startup noise occurring with systemd.

Yes, this was yet another difficulty that arose with the change to
systemd from rhel6 to rhel7.  The intent was to solve it first in fedora
when it switched to systemd to address this since the number of startup
messages jumped from manageable within the default backlog size to
almost double.  There are also other improvements upstream that remove
some of the doubt about exactly how many log messages were lost.

> Wow. Thanks Richard, I appreciate the answer on this.

It is all there in fedora and RHEL8, so that is one possible route.  It
is a bit late in the RHEL7 life cycle to commit to it, but not
impossible...

> LCB
> 
> -- 
> Lenny Bruzenak

- 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

Re: boot parameter question

[Lenny Bruzenak]

On 7/30/19 3:36 PM, Richard Guy Briggs wrote:

> On 2019-07-30 15:06, Lenny Bruzenak wrote:
>> On 7/29/19 4:32 PM, Richard Guy Briggs wrote:
>>> It is being ignored because that kernel command line extension to the
>>> original feature was never backported to RHEL7.
>> That would definitely do it.
>>
>>> In hindsight, that would have been pretty useful without causing much
>>> risk.  Normally feature backport is driven by customer demand.  There
>>> was a bit of pushback when it was first introduced upstream, but this is
>>> exactly the scenario I envisioned where it would be most useful.  It is
>>> possible to compile your own kernel and change the default value, but
>>> that's obviously a hurdle for most.
>> It would definitely have been useful, some might say even necessary,
>> given the audit event startup noise occurring with systemd.
> Yes, this was yet another difficulty that arose with the change to
> systemd from rhel6 to rhel7.  The intent was to solve it first in fedora
> when it switched to systemd to address this since the number of startup
> messages jumped from manageable within the default backlog size to
> almost double.  There are also other improvements upstream that remove
> some of the doubt about exactly how many log messages were lost.
>
>> Wow. Thanks Richard, I appreciate the answer on this.
> It is all there in fedora and RHEL8, so that is one possible route.  It
> is a bit late in the RHEL7 life cycle to commit to it, but not
> impossible...


Thanks Richard and I do appreciate the insight.

For some it might be possible to switch OS baselines effortlessly,
others (including my group) it isn't.

I'm surprised other RHEL 7 consumers are not squawking; I wonder if they
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?

For people who care, I'd say that examining the stats ("auditctl -s")
after startup would be worthwhile to see if they are losing events. Even
if on fedora or RHEL8, I guess if the default is still 64 they could
also be dropping relevant events they might want.

I know this isn't a new thing, and I should have been more diligent
myself, just saying.

LCB

-- 
Lenny Bruzenak
MagitekLTD

Re: boot parameter question

[Paul Moore]

On Tue, Jul 30, 2019 at 5:52 PM Lenny Bruzenak <lenny@magitekltd.com> wrote:
> On 7/30/19 3:36 PM, Richard Guy Briggs wrote:
> > On 2019-07-30 15:06, Lenny Bruzenak wrote:
> >> On 7/29/19 4:32 PM, Richard Guy Briggs wrote:
> >>> It is being ignored because that kernel command line extension to the
> >>> original feature was never backported to RHEL7.
> >> That would definitely do it.
> >>
> >>> In hindsight, that would have been pretty useful without causing much
> >>> risk.  Normally feature backport is driven by customer demand.  There
> >>> was a bit of pushback when it was first introduced upstream, but this is
> >>> exactly the scenario I envisioned where it would be most useful.  It is
> >>> possible to compile your own kernel and change the default value, but
> >>> that's obviously a hurdle for most.
> >> It would definitely have been useful, some might say even necessary,
> >> given the audit event startup noise occurring with systemd.
> > Yes, this was yet another difficulty that arose with the change to
> > systemd from rhel6 to rhel7.  The intent was to solve it first in fedora
> > when it switched to systemd to address this since the number of startup
> > messages jumped from manageable within the default backlog size to
> > almost double.  There are also other improvements upstream that remove
> > some of the doubt about exactly how many log messages were lost.
> >
> >> Wow. Thanks Richard, I appreciate the answer on this.
> > It is all there in fedora and RHEL8, so that is one possible route.  It
> > is a bit late in the RHEL7 life cycle to commit to it, but not
> > impossible...
>
> Thanks Richard and I do appreciate the insight.
>
> For some it might be possible to switch OS baselines effortlessly,
> others (including my group) it isn't.
>
> I'm surprised other RHEL 7 consumers are not squawking; I wonder if they
> 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