[PATCH] [RHEL/6] Search for nousb kernel command line argument in /etc/grub.conf within bootloader_nousb_argument check case-insensitively

Jan Lieskovsky jlieskov at redhat.com
Fri Apr 25 12:25:55 UTC 2014


Hello folks,

  1) apologize for my late reply (was on PTO in between).

----- Original Message -----
> From: "Shawn Wells" <shawn at redhat.com>
> To: scap-security-guide at lists.fedorahosted.org
> Sent: Thursday, April 17, 2014 2:23:31 AM
> Subject: Re: [PATCH] [RHEL/6] Search for nousb kernel command line argument	in /etc/grub.conf within
> 	bootloader_nousb_argument	check	case-insensitively
> 
> On 4/16/14, 5:08 PM, Kayse, Josh wrote:
> 
> 
> 
> On Apr 16, 2014, at 8:06 PM, Kayse, Josh < Joshua.Kayse at gtri.gatech.edu >
> wrote:
> 
> 
> 
> 
> 
> On Apr 16, 2014, at 7:59 PM, Shawn Wells < shawn at redhat.com > wrote:
> 
> 
> 
> 
> On 4/16/14, 5:44 AM, Jan Lieskovsky wrote:
> 
> 
> 
> Patch summary:
>   * check for 'nousb' argument on kernel command line in /etc/grub.conf
>     within the bootloader_nousb_argument check in a case-insensitive way
>   * update comments where appropriate
>   * add test attestation timestamp
>   * replace path + filename ind construct with filepath one
> 
> Testing report:
>   * Tested on RHEL-6. Works fine.
> 
> I wasn't sure if nousb was case insensitive, so I checked
> https://www.kernel.org/doc/Documentation/kernel-parameters.txt
> 
> And found this:
> 
> 
> 
> Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
> a trailing = on the name of any parameter states that that parameter will
> be entered as an environment variable, whereas its absence indicates that
> it will appear as a kernel argument readable via /proc/cmdline by programs
> running once the system is up.
> 
> "nousb" was in the list as case sensitive.

Checked the three (selinux, audit & nousb) options again, and now it looks
they truly are case sensitive (only lowercase ones cause the desired effect).

> 
> Applied your patch (RHEL 6.5), added "nOuSB," and things seem to check out.
> Should we follow the kernel docs (which say case sensitive), or allow
> insensitivity since it actually works?
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> 
> I’d like to point out that the selinux parameter is also within that list. I
> vote we should follow what actually works and assume the kernel docs are out
> of date.
> 
> -josh
> 
> Also, according to
> https://github.com/torvalds/linux/blame/master/Documentation/kernel-parameters.txt
> that line was last changed 2005. Perhaps someone should brave lkml and
> submit a patch.

On the system, I was checking the change there's been broken symbolic link /etc/grub.conf ->
/boot/grub/grub.conf, so changing /etc/grub.conf command line didn't actually had effect
on what got actually provided to the kernel's command / boot line (verified by
cat /proc/cmdline on running system).

Editing /boot/grub/grub.conf directly (instead of /etc/grub.conf) with SELINUX=0, AUDIT=1,
or NOUSB doesn't seem to cause anything different from the default behaviour. 

Also checked with Petr Matousek (Red Hat's SRT representative for kernel) and he confirmed,
the options should still be case sensitive, as visible in the code:
  http://lxr.linux.no/#linux+v3.14.1/kernel/params.c#L180

(there isn't section in parse_args() routine which would convert argument to
it's lowercase prior checking for match).

Long story short, on the default RHEL-6 system, where /etc/grub.conf symlink
to /boot/grub/grub.conf is not broken (and thus /etc/grub.conf change is actually
projected when booting / re-booting) only lowercase version of the options is honoured.

So we should keep the current form of all three SCAP tests (checking audit, nousb & selinux options),
and those three patches:
  https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/005291.html
  https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/005292.html
  https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-April/005293.html

should NOT be applied, since they are wrong.

But this case (broken symlink from /etc/grub.conf to /boot/grub/grub.conf) made me to wonder
if instead of checking /etc/grub.conf those tests shouldn't be checking /boot/grub/grub.conf
configuration file directly (AFAICT both /etc/grub.conf and /boot/grub/menu.lst are just
symbolic links to /boot/grub/grub.conf).

Sorry for the confusion (hopefully the above clears it).

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

> 
> -josh
> 
> Thanks for that link!
> 
> Ack to Jan's patch.
> 
> 
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>


More information about the scap-security-guide mailing list