lkml.org 
[lkml]   [2023]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v15 01/11] LSM: Identify modules by more than name
    From
    On 10/21/2023 5:20 AM, Tetsuo Handa wrote:
    > On 2023/10/21 4:52, Casey Schaufler wrote:
    >> On 10/5/2023 5:58 AM, Tetsuo Handa wrote:
    >>> On 2023/09/13 5:56, Casey Schaufler wrote:
    >>>> Create a struct lsm_id to contain identifying information about Linux
    >>>> Security Modules (LSMs). At inception this contains the name of the
    >>>> module and an identifier associated with the security module. Change
    >>>> the security_add_hooks() interface to use this structure. Change the
    >>>> individual modules to maintain their own struct lsm_id and pass it to
    >>>> security_add_hooks().
    >>> I came to worry about what purpose does the LSM ID value (or more precisely,
    >>> "struct lsm_id") is used for. If the LSM ID value is used for only switch
    >>> {reading,writing} /proc/self/attr/ of specific LSM module's information, only
    >>> LSM modules that use /proc/self/attr/ will need the LSM ID value.
    >>>
    >>> But this series uses "struct lsm_id" as one of arguments for security_add_hooks(),
    >>> and might be reused for different purposes.
    >>>
    >>> Then, BPF-based LSMs (which are not considered as in-tree LSM modules, for
    >>> only BPF hook is considered as in-tree LSM module) might receive unfavorable
    >>> treatment than non BPF-based LSMs?
    >>>
    >>> [PATCH v15 05/11] says
    >>>
    >>> Create a system call to report the list of Linux Security Modules
    >>> that are active on the system. The list is provided as an array
    >>> of LSM ID numbers.
    >>>
    >>> The calling application can use this list determine what LSM
    >>> specific actions it might take. That might include choosing an
    >>> output format, determining required privilege or bypassing
    >>> security module specific behavior.
    >>>
    >>> but, at least, name of BPF-based LSMs won't be shown up in lsm_list_modules()
    >>> compared to non BPF-based LSMs? Then, the calling application can't use this
    >>> list determine what BPF-based LSM specific actions it might take?
    >> That is correct. Just as knowing that your system is using SELinux won't
    >> tell you whether a specific action might be permitted because that's driven
    >> by the loaded policy, so too knowing that your system is using BPF won't
    >> tell you whether a specific action might be permitted because that's driven
    >> by the eBPF programs in place.
    > If the system call returning LSM ID value for SELinux but does not tell
    > the caller of that system call whether a specific action might be permitted,
    > what information does LSM ID value tell?

    It tells the caller that the LSM is active on the system. That's it.
    Just like reading /sys/kernel/security/lsm.

    >
    > The patch description lacks relationship between LSM ID value and data.
    > In other words, why LSM ID values are needed (and are useful for doing what).
    > If the only information the caller can know from the LSM ID value were
    > what LSMs are enabled (i.e. the content of /sys/kernel/security/lsm ), why
    > bother to use LSM ID values? (Yes, integer comparison is faster than string
    > comparison. But that is not enough justification for not allowing out-of-tree
    > LSMs and eBPF-based access control mechanisms to have stable LSM ID values.)
    >
    > What does "choosing an output format", "determining required privilege",
    > "bypassing security module specific behavior" mean? How can they choose
    > meaningful output format, determine appropriate privilege, bypass security
    > module specific behavior (if the only information the caller can know from
    > the LSM ID value were what LSMs are enabled) ?

    If Smack and SELinux not enabled on the system there is no point in
    setting up a netlabel configuration, for example.

    >> I wish we could stop people from saying "BPF-based LSM". BPF is the LSM. The
    >> eBPF programs that implement a "policy" are NOT a LSM. There needs to be a
    >> name for that, but LSM is not it.
    > My understanding is that "BPF is not an LSM module but infrastructure for using
    > LSM hooks".

    As BPF is implemented as a LSM I suggest your statement is incorrect.

    > Say, an access control implementation consists of two parts; "code" and "data".
    > The "code" is written by developers and is determined at compile time and is
    > interpreted by CPU, and the "data" is written by administrators and is interpreted
    > by "code". The "data" part can be either built-in (determined at compile time) or
    > loadable (configurable at run-time).
    >
    > eBPF-based access control implementations (which can be loaded via bpf() system
    > call after boot) consists of "code" and "data". BPF will remain no-op unless
    > eBPF-based access control implementations are loaded via bpf() system call.
    > Thus, I believe that an eBPF-based access control implementation should be
    > considered as an LSM module (like SELinux etc.)

    And I say you're wrong. Your arguments are gibberish.

    https://www.youtube.com/watch?v=-7cUnID7vFs

    \
     
     \ /
      Last update: 2023-10-21 16:12    [W:3.223 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site