-- 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?
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 08:53:50 PDT