Progress in security module stacking

Posted Mar 12, 2015 9:52 UTC (Thu) by rwmj (guest, #5474)
Parent article: Progress in security module stacking

I'm assuming that all the end user will see is EACCES/EPERM. The critical issue to me is that we get more detailed debug when a permission check fails, and ideally from the kernel instead of having to dig around in separate SELinux/AppArmor/other tools and log files.

to post comments

Progress in security module stacking

Posted Mar 12, 2015 23:47 UTC (Thu) by peter-b (guest, #66996) [Link] (1 responses)

I seem to remember that reporting a detailed reason for EACCES/EPERM to the violating process can cause an information leak.

Progress in security module stacking

Posted Mar 15, 2015 21:33 UTC (Sun) by skissane (subscriber, #38675) [Link]

For every failed access decision, generate a random token (e.g. a UUID), record that token both in the LSM's audit logs and return it to the calling process, which then logs it using its usual mechanisms (e.g. print to stderr, write to some log file etc). Provide a utility which requires elevated privileges to run (e.g. root, membership of some group, etc), which when given such a token, scans the LSM's audit logs, and generates the detailed information on why the access attempt was rejected. That way, there is no information leak - you need to be privileged to find out why the access attempt failed - but for those with privilege it should be easier than it is at present.