Bug 145009

Summary: [patch] rc.subr(8): rc.conf should allow mac label configuration
Product: Base System Reporter: Michael Reynolds <michael.reynolds>
Component: confAssignee: Hiroki Sato <hrs>
Status: Open ---    
Severity: Affects Only Me CC: hrs, ta0kira
Priority: Normal    
Version: 8.0-STABLE   
Hardware: Any   
OS: Any   
Description Flags
patch for rc.subr on 10.0-RELEASE-p7
patch for rc.subr on 10.0-RELEASE-p7 none

Description Michael Reynolds 2010-03-24 18:50:01 UTC
rc.conf, via rc.subr, should allow service specific labels to be set, so as to efficiently handle security, and ensure a working machine after enabling MAC.

Fix: Apply the affixed patch, add this (as an example) to your rc.conf:


Patch attached with submission follows:
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-03-24 23:21:15 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-rc

Over to maintainer(s).
Comment 2 Kevin Barry 2014-08-21 22:54:21 UTC
Created attachment 146135 [details]
patch for rc.subr on 10.0-RELEASE-p7
Comment 3 Kevin Barry 2014-08-21 22:54:29 UTC
Here is a more general solution that involves setting the login class and processing /etc/login.conf. It relies on the program attached to bug 192900 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192900), which processes /etc/login.conf and optionally sets the MAC label.

The attached patch modifies /etc/rc.subr so that it by default applies the "daemon" login class when running an rc.d script, with possible exceptions made in the new file /etc/rc.exempt. Each line specifies the full path name of an rc.d script (e.g., /etc/rc.d/sshd), and an optional login class following a colon (e.g., /etc/rc.d/sshd:sshd, for login class "sshd"). If no login class is specified, "default" is used. So, with the rc.subr patch, sshd would be; by default, run under login class "daemon"; run under login class "default" if "/etc/rc.d/sshd" is in /etc/rc.exempt; and run under login class "sshd" if "/etc/rc.d/sshd:sshd" is in /etc/rc.exempt.

This isn't a perfect solution, but it's a start. Note that 'eval "$(set)"' (line 50 of the patch) isn't ideal, but it seems to be necessary, since some rc.d scripts (e.g., fsck) assume that they're going to be sourced, rather than executed.
Comment 4 Kevin Barry 2014-08-21 22:56:54 UTC
Created attachment 146136 [details]
patch for rc.subr on 10.0-RELEASE-p7
Comment 5 Hiroki Sato freebsd_committer 2014-11-04 00:27:35 UTC
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:43:40 UTC
batch change:

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


Reset to open status.

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.
Comment 7 Kevin Barry 2020-12-29 00:09:57 UTC
rc.subr also doesn't set the login class (affects rctl and rlimit enforcement), even when foo_login_class is used in the rc.d script.

I proposed a simple program in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192900 to apply the login class from login.conf, including its MAC label. With that, both rc issues can be fixed by including a call to that program in $_doit in rc.subr and then setting foo_login_class in rc.d/foo.