lkml.org 
[lkml]   [2014]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/7] security: introduce kernel_fw_from_file hook
    On Mon, Jul 14, 2014 at 02:38:13PM -0700, Kees Cook wrote:
    > +int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
    > +{
    > + return security_ops->kernel_fw_from_file(file, buf, size);
    > +}
    > +EXPORT_SYMBOL_GPL(security_kernel_fw_from_file);

    I have a use case in mind already (CRDA) whereby a non-driver but a core part of
    the kernel would like to use the request_firmware_direct() API and leave
    it optional to that part of the kernel if or not a digital signature check
    is required since this is already an optional feature. Since LSM would be
    used for the digital signatures it it'd be good if we allowed drivers and
    the kernel to specify whether or not a the LSM signature hook does indeed
    need to be used.

    Additionally there may be different signature requirements on the file, one
    might be willing to *require* a digital signature check even if say dm-verity
    was used, one use case here is wanting the to require as part of the
    specification a one to one mapping of file --> signature. That may be a
    bit paranoid... but its certainly a possibility. This could be addressed by
    allowing a user to express whether one security mechanism is sufficient
    for an expected one, or if one is definitely required. One example here
    could be the ability for a driver / kernel to express that dm-verity would
    not suffice for a request_firmware_direct() call. I'm not saying that I
    *know* this use case exists, am just saying I can expect it and do consider
    it subjective to assume we'd agree on possible security intersections.

    I see this also adds a hook for fw itself, meanwhile we already had one for
    modules. The request_firmware() API is already used on other areas of the
    kernel for non-firmware files, it can be used to load optional CPU microcode
    upgrade, EEPROM optional override files, and in the wireless case I'd like to
    see if we could replace CRDA by using the same APIs / mechanisms as well to
    avoid having to deal with complexities on parsers with CFG80211_INTERNAL_REGDB.
    Besides nomenclature fuzz as usage of request_firmware() API grows it occurs to
    me that perhaps these hooks could be generalized at the kobject granularity
    level. That should make it easier to scale and consider these LSM hooks for any
    type of other object in the kernel in the future. kobjects may be overkill
    though, unless we could enable the option to have have these hooks only
    optional for certain type of kobjects.

    Luis


    \
     
     \ /
      Last update: 2014-07-15 01:01    [W:2.789 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site