I locally have very small changes to this revision, essentially whitespace fixes and the introduction of a new flag MDF_EXPLICIT_SUPP_MUST as an impact of the update of D47620.

Rework as to check for explicitly denied or mandatory groups in mac_do_priv_grant(), for reasons explained above.

Fix the public setcred() prototype.

Apply suggestions. Fix some whitespace issues. Remove #if __BSD_VISIBLE.

In D47881#1091936, @imp wrote:

So if sys/_types.h won't suffice, I'd call out why in the commit message (this file makes no pretense of being namespace clean I think would be the reason.)

In D47887#1092651, @imp wrote:

Yes. A the same time, though, new members have to accept that our culture does have a large element of collective experience (...)

In D47618#1092557, @brooks wrote:

Looks good! A few quibbles (mostly things that would make things easier for use in CheriBSD), but nothing mandatory.

In D47887#1092313, @imp wrote:

For what it's worth, we do discuss these things in public all the time.

In D47618#1091926, @imp wrote:

So about thr_new: Just create a new thr_new and rename the old one. Don't try to make it versioned. That's useless. We have lots of system call numbers and trying to 'repurpose' an old system call in an overly clever way just makes my job at implementing it for bsd-user a lot harder. And it doesn't really help. We've renamed the old system call several times, I suggest you just keep it simple like that.

Remove the blank line at start of functions with no local variables added to MAC.

Remove the explicit version bits in flags and the _v0 suffix for the setcred()'s structure.

Apply brooks@'s request and suggestion.

I thought we'd already went this far

In D47879#1091920, @kib wrote:

I think more relevant question there are compilers generate proper code to access unaligned ifid_ino and ifid_start on sensitive arches.

In D47618#1086045, @brooks wrote:

I like the overall idea.

Add missing 32-bit compatibility code.

I've checked that nobody takes the address of the unaligned members.

I tend to agree with kib@ for both of its inline comments. The second comment is the second alternative I listed. I'm fine either way.

This revision will be reworked. The way that the mac_cred_check_setcred() hook implements active rejection (mandated by target clauses containing -gid=<gid> and/or !gid=<gid>) isn't compatible with inclusive disjunction of several rules. My initial intention in using mac_cred_check_setcred() was that mac_do(4) could restrict transitions that even other MAC modules would have authorized, but I don't think this was a wise choice, as mac_do(4) anyway applies only to a fraction of process (those spawned from /usr/bin/mdo). So, instead of fixing mac_cred_check_setcred(), I'll move the "active rejection of credentials transitions" code into mac_do_priv_grant().

Fix style (v & FLAG => (v & FLAG) != 0 and similar).

Rename alloc_parse_error() to make_parse_error() (as it is a constructor really, not just an allocator).

Here are some examples:

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=*,+gid=*

Gives UID 10001 the rights to become UID 10002 and become part of any group. This is basically the equivalent of today's sysctl security.mac.do.rules=uid=10001:10002. Both mdo -u 10002 and mdo -u 10002 -i will work.

sysctl security.mac.do.rules=uid=10001:uid=10002

Allow UID 10001 to switch to UID 10002, but only keeping the exact groups he's already in. So, mdo -u 10002 -i will work, but not mdo -u 10002 (unless UID 10002's groups are exactly UID 10001's groups, or that of the current process if they were modified).

sysctl security.mac.do.rules=uid=10001:uid=10002,uid=10003

Same, but also allows to switch to UID 10003 instead.

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002

Same, but the new primary groups must be set to 10002, and no supplementary groups should be set. In particular, mdo -u 10002 will work (if UID 10002's primary group specification is GID 10002, and only if /etc/group doesn't enroll 10002 into any supplementary group), whereas mdo -u 10002 -i will not (unless UID 10001 is also member of the single (primary) group 10002).

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,+gid=.

Same as the previous, but allows to retain any current supplementary groups. mdo -u 10002 -i will work, and mdo -u 10002 also (unless UID 10002 has a different primary group than 10002 or is part of supplementary groups that are not already current).

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,!gid=.

Same as the previous, but *must* retain exactly all current supplementary groups. Compared to the previous example, this will cause mdo -u 10002 to fail unless UID 10002's supplementary groups are exactly those currently in force.

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,+gid=.,-gid=10001

Same as sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,+gid=. above, but 10001 cannot be retained as a supplementary group. mdo -u 10002 -i will work but only if 10001 is not present as a supplementary group, and mdo -u 10002 will work (unless UID 10002 has a different primary group than 10002 or is part of supplementary groups that are not already current).

sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,+gid=.,!gid=10003

Same as sysctl security.mac.do.rules=uid=10001:uid=10002,gid=10002,+gid=. above, with the additional constraint that 10003 must appear in the supplementary groups. Both mdo -u 10002 -i and mdo -u 10002 will continue to work as explained for that previous case, but only if, respectively, 10003 is a supplementary group of the current process and UID 10002's is in supplementary group 10003 (according to /etc/group).

sysctl security.mac.do.rules=gid=100000:uid=0

Makes 100000 a wheel group on steroid, allowing to switch to root without password (with the current state of mdo(1); we could modify the latter to request passwords in some cases, in which case security is weakened as this check would be performed by userland and not mac_do(4), but this is probably perfectly acceptable in less strong, common threat models).

The following transitions, as they only involve GID changes, cannot currently be required through mdo(1), but I think would be valuable to support:

sysctl security.mac.do.rules=gid=10001:gid=10002

Allow users of GID 10001 to enter GID 10002 as a primary group, but only if giving up all their supplementary groups.

sysctl security.mac.do.rules=gid=10001:gid=10002,+gid=.

Same as the previous, but allows to retain any current supplementary groups.

sysctl security.mac.do.rules=gid=10001:gid=10002,!gid=.

Same as the previous, but *must* retain exactly all current supplementary groups.

In D47616#1086740, @lwhsu wrote:

I read the commit message and haven't finished the code. The GID rules seems having much more features and I would like to know more. Do you think you can share some use scenarios and how to config the rule? I believe it would also be useful to have these in mac_do(4).

Style fixes (v & FLAG => (v & FLAG) != 0 and related), add missing
redundancy check for UIDs (no UID can appear twice or more in target clauses).

Move some not-directly-related change to other revisions (existing ones, and a new one, D47772).

Remove a redundant check that was forgotten in the previous update.

This is a followup to the change in D47613 (u_int used for IDs). Took the
occasion to provide a better implementation that supports negative number
specifications (as strtou*() standard functions do).

Use u_int instead of int, as uid_t and gid_t are in fact unsigned integers, and not signed ones as I initially assumed. (Since we are compiling with -fwrapv, this doesn't matter for correctness of execution, but is conceptually wrong.)

Ping?

In D47622#1087421, @olce wrote:

In D47622#1086652, @emaste wrote:

Slightly more efficient at the cost of being inconsistent during the deletion; no objection from me.

Yes, but the inconsistency can only be observed by concurrent accesses which are not meant to happen, and if they still did because of improper locking, the initial version is not safe either as TAILQ_REMOVE() is not atomic.

In D47624#1086651, @emaste wrote:

It's worth expanding the commit message - even if there's no functional change intended we should say why we're bothering with the change. Presumably it is because we only ever iterate over these in the forward direction so we can avoid the additional overhead.

But, LGTM.

In D47622#1086652, @emaste wrote:

Slightly more efficient at the cost of being inconsistent during the deletion; no objection from me.

In D47594#1086927, @bapt wrote:

same about the commit message

In D47593#1086924, @bapt wrote:

the commit message, should clarify the consistency purpose imho.

In D47598#1086937, @bapt wrote:

I can see now the comment from D47598 is now useless :D

No concern, we should just be (eventually) consistent and either prefer and use these here and in general, or if we don't prefer them we should abandon this review.

I have the same thought. Although these two functions are trivial, I like its encapsulation and think it should be used in general when possible. It seems we have many mtx_{,un}lock wraps in the code, although mostly in the form of macro, and seems limited to the scope of a single driver.

In D47592#1086653, @emaste wrote:

Commit message should explain why something was done not (just) what; in this case it the reason is fairly clear from context but still needs the reader to look at the change and understand.

In D47591#1086749, @lwhsu wrote:

Note 0 and \0. I believe the later is better.