Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Michael Stone <michael <at> laptop.org>
Subject: Re: A basic question about the security_* hooks
Newsgroups: gmane.linux.kernel.lsm
Date: Friday 25th December 2009 01:11:29 UTC (over 7 years ago)
Serge Hallyn writes:
> Michael Stone writes:
>> In particular, what would be worse about a kernel in which each security
hook
>> contained nothing but conditionally-compiled function calls to the
appropriate
>> "real" implementation functions with early-exit jumps on non-zero return
codes?
>
> The problem is that composing any two security policies can quickly have
> subtle, unforeseen, but dangerous effects. 

First, thanks very much for your helpful explanations and pragmatic advice.

Second, two thoughts and a question:

   1. I think you're probably correct when we're discussing security
policies
      chosen uniformly at random from the space of all possible such
policies.
      However, I believe that the cost-benefit ratio favors composition
quite
      strongly when we're discussing real security policies which where
designed
      with composition in mind, as is the case with my work.

   2. The problem you cite is an inherent property of software assurance
which
      is indepedent of software assurance of information-security-specific
      properties. Thus, while you are correct that composition sometimes
makes
      it harder to assure a system due to the increased number of "moving
      parts" that have to fit together perfectly, it also frequently makes
the
      assurance problem more tractable by reducing the cost to assure the
      individual pieces which are being composed.

   3. Have you any specific examples of problems that have been clearly
averted
      by the current arrangement?

> So with your module, I'd recommend following the route of the
capabilities
> LSM. You can provide an optional stand-alone LSM which only hooks your
> functions. Then smack, for instance, can call the functions in your LSM
> from within its own hooks, or it can simply explicitly assign its hooks
to
> your functions in smack_ops.  Selinux can do the same thing, although I
> suspect they would more likely implement their own functions for your
newly
> hooked sites.

Doesn't it seem a bit strange to you to be recommending that everyone else
using the five security hooks I want to use modify their code *in detail*
to
support my functionality given that my functionality is explicitly intended
not
to require any such work on their part?

This seems frankly silly to me, not to mention expensive and error-prone.

Instead, perhaps we'd be better off with something like a declarative
compile-time whitelist or blacklist for compositions?

Regards,

Michael
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 4ms