Re: linux-security-module digest, Vol 1 #43 - 14 msgs

From: Kurt P. Hundeck (khundeckat_private)
Date: Mon Apr 23 2001 - 23:28:24 PDT

  • Next message: Crispin Cowan: "Re: A Comment from User Space"

    >   if (access()) { open(); }
    > code sequence is inherently vulnerable to TOCTTOU attacks (race conditions).
    > You'd have to invent a new, secure interface to get this right, and access()
    > isn't it.  Haven't I explained this about five or six times now?
    > 
    > Errr.. I'll need a lot more convincing before I think an access()-like
    > function is a workable security measure.
    
    I personally don't think that anyone here is arguing that.  Clearly not
    having autonomous check/do action is a large obvious problem.
    
    > I think the whole idea is fundamentally flawed. Forcing module guys to
    > implement an access()-like function (whether for information purposes or
    > for broken security checking) doesn't seem right.
    > 
    > If you want to support it in your module, go right ahead. But I don't
    > think it should be forced on anyone -- because it cannot promise to be
    > correct except in situations where their correctness doesn't matter.
    > (i.e., when no one is actively attacking the system.)
    
    However a system that maintains a lsm_error is very do able without
    changing or adding anything (well we'll see about that...:-))  Could a
    system work like this:
    
    	1) Some body asks the kernel to do something
    	2) Kernel does something, but first! (maybe), it calls a hook.
    	3) If that hook fails, the kernel function bails passing back a
               -EPERM, or whatever.
    	4) Programmer checks error value.
    
    Now.  I know this solution has thread safety issues, but perhaps there is
    something else that could be added.
    
    Or, a solution might work look like this:
    
    	1) Joe programmer hooks his own function that gets called
               everytime a hook fails inside the current security module.
    	2) Calls some sys function / kernel function.
    	3) Kernel Function calls hook.
    	4) Security module hook fails, hook code calls userland registered
               hook.
    	5) Userland registered hook populates a data structure or
               something.
    	6) Everything trickles back to userland with the -EPERM (or
               whatever)
    	7) Userland realizes there was an error and checks their data
    	   structure.
    
    Now I am pretty sure this is thread safe.  But who knows.  I really don't
    know too much about this stuff.
    
    Kurt P. Hundeck
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 23:29:57 PDT