Re: permissive vs. restrictive issue and solutions...

hdholmat_private

I wanted to add a couple of thoughts to this discussion.  Let me first
attempt to summarize my understanding of the discussion so far.  If I
didn't understand someone's perspective, obviously that will taint my
conclusions.

The argument seems to have narrowed to a discussion of the wisdom of
moving all the security decision logic (i.e., POSIX-like DAC and
capabilities) into LSM modules as opposed to having modules that
provide additional restrictive-only security logic and leaving DAC and
capabilities in the base kernel.  I'm not entirely certain if option number
2 from the original post

    "2. Maintain current set of hooks and push logic out of the kernel
    and into the module to avoid placing hooks in compound
    conditionals."

really called for the migration of all security logic or not.  But
since the discussion seems to have gone that way, I'll assume that's
the intent.  Ignoring for the moment arguments of which is more
elegant, the arguments I've seen for including all security logic in
LSM are: 1) some security projects (e.g., SELinux) may desire to
provide additional capability-like permissive authorization;  2) all
the security logic is collected and can be reviewed more easily;  3)
interaction between policies is slightly easier to manage because the
module gets to control all interaction with the base-policies; and 4)
it allows the complete removal of security logic when not desired
(e.g., embedded systems.)  The arguments I've seen against including
all security logic are: 1) the base logic would have to be reproduced
(possibly incorrectly) for each module, and 2) reasoning about the
security of the kernel is more difficult.

While it is true that adding only restrictive security allows you to
more easily determine that no additional access was given to a
resource, I resist the notion that such an analysis is an "assurance
argument."  I would suggest that security is not mearly restricting
access from those who shouldn't have it, but also allowing access to
those who should.  A system that denies all access is not particularly
useful and only secure in the "it's a secure brick" sense.  Denial of
service (AKA availability) is also a security concern.

The argument that duplicating the base logic would violate software
engineering priniciples ignores the fact that there is a difference
between sharing of source code and sharing of binary code.  While
sharing the binary implementation of the base security would be
possible, but difficult, sharing the source code is possible and less
difficult.  Since this is, after all, an open source effort, I would
think it possible to create a file of (inlineable) functions to perform
POSIX-like DAC checks and capability checks.  If a module wants those
features, it should be easy enough to incorporate the base functions.
If there is an error in the base functions, it's easy enough to fix and
the fix propogates at the next compile of the kernel and it's modules.
Of course, the specifics of contructing base logic functions is
probably another long discussion.  It has also been pointed out to me
that reusable base logic is very much like stackable security modules,
but I think in implementation avoids some of the problems and
complexity of a generalized stackable security module architecture.

In summary, if you haven't already guessed, I'm finding the arguments
for migrating all security logic into modules more compelling than
those against.

--
Howard Holm <hdholmat_private>
Information Assurance Research Office
National Security Agency

Jesse Pollard wrote:
> 
> Either of these improves the kernel for the embeded Linux group, and
> still preserves the current operation by having it in the LSM core.
> 
> Configuration of this should be something along the lines of:
> 
> Embedded Linux ?	-> no LSM required, and no security overhead
> 
> Basic Security ?	-> the base LSM with the current implementation
> 			   compiled into the kernel. (ie. not a loadable
> 			   module) It should still be available if embedded
> 			   Linux is chosen.
> 
> LSM module ?		-> base LSM as a module.
> capabilities ?		-> base LSM + capability (might be loadable if previous
> 			   option taken)

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module