Hello folks,

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

----- Original Message -----
> From: "Shawn Wells" <[email protected]>
> To: [email protected]
> 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 < [email protected] >
> wrote:
> 
> 
> 
> 
> 
> On Apr 16, 2014, at 7:59 PM, Shawn Wells < [email protected] > 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
> [email protected]
> 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
> [email protected]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to