Bug 177699 - Documentation (handbook and manpage) for mac_biba doesn't mention its impacts on root privileges.
Summary: Documentation (handbook and manpage) for mac_biba doesn't mention its impacts...
Status: Open
Alias: None
Product: Documentation
Classification: Unclassified
Component: Documentation (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-doc mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-08 00:50 UTC by Kevin Barry
Modified: 2018-05-28 19:49 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Barry 2013-04-08 00:50:00 UTC
The documentation for mac_biba (`man mac_biba` and http://www.freebsd.org/doc/en/books/handbook/mac-biba.html) completely neglects to mention that certain root privileges are lost if a process cannot attain biba/equal. A few examples of those privileges: setting the login class of a process; changing audit settings with auditon(2). Importantly, the latter prevents users from using su and sudo if their MAC label isn't compatible with biba/equal. Whether or not this is a core feature of the FreeBSD Biba implementation, users should be made aware of it up front in the documentation. I figured it out because I'm well-versed in C and I spent a few days tracking down why I couldn't use su and sudo; however, the majority of FreeBSD users probably aren't C programmers.

Fix: 

The list of privileges lost if the process cannot attain biba/equal are available in biba_priv_check (/usr/src/sys/security/mac_biba/mac_biba.c:1868). Additionally, everywhere the biba_subject_privileged function is used in mac_biba.c indicates some sort of kernel functionality that is blocked.
How-To-Repeat: Please note that the steps below reproduce one of the *undocumented* behaviors of mac_biba. The problem is the lack of documentation, not the behavior.

- Enable mac_biba.
- Given a username "user", try `setpmac 'biba/high(high-high)' su user true`. You should get "Permission denied", as well as a message referencing auditon failure in /var/log/messages.
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:00 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.