Re: A Comment from User Space

From: Valdis.Kletnieksat_private
Date: Mon Apr 23 2001 - 08:51:17 PDT

  • Next message: Alexander Reelsen: "Re: A Comment from User Space"

    -- 
    				Valdis Kletnieks
    				Operating Systems Analyst
    				Virginia Tech
    On Sat, 21 Apr 2001 09:24:29 EDT, jmjonesat_private said:
    > I don't think security-aware-polite programs are "broken" if they want
    > to use access() to "size up the situation", but, it would seem to me,
    > an advantage of an LSM in the first place is to harden the underbelly
    > enough that applications DON'T REALLY NEED to provide too much of their
    > own security checking on an application by application basis.  Good
    > programs will never see the policy restrictions (once the poor bedraggled 
    > admin has them set up properly to support the program), and a cracked
    > program... well, hopefully it'll run into a brick wall.
    
    What would people think of a defined interface to allow the LSM to
    tell the application more than 'errno = EFASCIST; return', so that
    *if* the LSM in effect *wanted* to provide back more detail, it could?
    
    This would allow the LSM to tell a security-aware-polite program more,
    so it could do a better job than just 'perror()'.
    
    Something to remember here - for many cases, there *will* be programs
    that are *not* part of the kernel, but *are* inside the trusted
    perimeter.  For instance, the SELinux stuff has a modified vixie-cron,
    passwd, and so on, to make sure that things like security contexts are
    kept correct.
    
    Since things that are "inside" will of course have to be written in
    conjunction with the LSM in use *anyhow*, I think we can get away with
    saying:
    
    "On an access error, the LSM will set the process external var 'errno'
    to EFASCIST, and fill in the structure pointed to by the user process
    'struct *lsm_opaque_data *sec_err_explain' (after checking that the
    pointer is non-NIL and in the address space and all that)".
    
    That way, for instance, SELinux could fill in the pointer to pass info
    back to /bin/passwd if it desired, and RBSAC could fill it in as it
    needed, and so on.  We *may* want to have a 2-4 byte magic cookie
    at the front, identifying the LSM in effect, so programs written to
    support multiple LSM can identify which one is being used.
    
    Comments?
    
    
    
    

    _______________________________________________ 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 - 08:53:50 PDT