Re: Legitimate Question

crispinat_private

jmjonesat_private wrote:

>Yes, this is the function that I envision needing, and had hoped there
>might be some possibility of providing some minimally common interface 
>to query the policy (or more specifically, test an access against a
>specified policy other than their own) by applications with permission 
>to do so.
>
>The stalwart rejection of such commonality is probably good
>design/security thinking, but not having a common means to do 
>this thing which I think may prove a common need is an 
>inconvenience, IMHO.  *SHRUG* :)  It would probably be impossible
>to design a flexible enough call, anyway, to address the supported
>diversity of modules.
>
Excactly. I understand why you want it, but no matter how much you want 
it, you can't have it because it's not feasible.

It would be lovely, for both security and practical engineering reasons, 
if there was One True Security Model, and then everyone could just code 
to it. Unfortunately, decades of head-butting have not resolved that 
question, and so there just isn't a common model.

The entire LSM project exists precisely for that reason: so you can load 
the wacky module of your choice into a standard kernel. If there was One 
True Security Model, you wouldn't need LSM.

Since you can load wacky security models, there is no way of 
standardizing a way of querying "what if" policy questions:

    * You can't count on a test program with the same uid to test,
      because some policies might impose different rules on different
      programs with the same uid.
    * You can't count on the application itself to test and then enable
      something, because some policies might impose different rules
      depending on the time of day, or even on how often you ask.

For a realistic example of the latter, consider RaceGuard:

    * The normal way to create a temp file is to
         1. nominate a file name, e.g. /tmp/fooprog.pid
         2. stat for the existance of that file.
         3. if it does not exist, go ahead and create it.
    * Race attacks happen between 2 and 3, where the attacker drops a
      symlink or hard link from /tmp/fooprog.pid to (say) /etc/hosts.allow.
    * RaceGuard caches names presented to stat that return "not found"
      and monitors calls to creat & open that match the RaceGuard cache
      and hit files that *do* exist. If so, the open gets denied.

So here's a completely legitimate example of a policy that says that a 
single process cannot do something it was permitted to do a moment ago, 
because conditions have changed.

In practice, for JMJ's install purposes, this is unlikely to be a 
problem. RaceGuard is preventing you from shooting yourself in the foot, 
and install scripts are unlikely to do this. More likely, some attacker 
is race-attacking the install script, in which case RG is doing its job.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

        The Olympic Games: A Century of Corruption and Graft

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