[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