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

Kayse, Josh Joshua.Kayse at gtri.gatech.edu
Fri Apr 25 12:52:25 UTC 2014


On Apr 25, 2014, at 8:25 AM, Jan Lieskovsky <jlieskov at redhat.com> wrote:

> 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).
> 

I went looking to find where it was allowed to be insensitive and couldn’t find it so I’m glad I wasn’t missing something.

> 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).
> 

I’ve seen this a lot due to bugs in augeas or perl modifications of /etc/grub.conf instead of /boot/grub/grub.conf and therefore I recommend that /boot/grub/grub.conf is checked instead of /etc/grub.conf

-josh
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3471 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140425/927b0765/attachment.p7s>


More information about the scap-security-guide mailing list