mac_grantbylabel focused priv escallation via maclabel

[sjg]

Summary

This module leverages labels set via mac_veriexec
to provide priv escallation to specific applictaions.

[sjg]

missed modules

[sjg]

Ed, let me know who else should look...

[sjg]

revert change to veriexec_fingerprint.c

[sebastien.bini_stormshield.eu]

lib/libveriexec/exec_script.c

118

I don't see how this could work if interpreter has the indirect flag.

The new PRIV_VERIEXEC_DIRECT is never queried to grant that privilege to the process. Unless I am missing something?

[sebastien.bini_stormshield.eu]

sys/security/mac_veriexec/mac_veriexec.h

160

Why is the ve_mutex never taken when calling this function?

Also, it seems safer imo to return a copy of the label (as done here https://reviews.freebsd.org/D36506) as you never know whether some other thread may overwrite the label while you are inspecting it.

sys/security/mac_veriexec/veriexec_metadata.c

141–142

Why is this no longer freed?

[sjg]

lib/libveriexec/exec_script.c

118

I thnk there are some updates to mac_veriexec needed - in our tree it calls
mac_priv_grant(td->td_ucred, PRIV_VERIEXEC_DIRECT)

sys/security/mac_veriexec/mac_veriexec.h

160

Who would take the mutext? it is only used within veriexec_metadata.c and is take by get_veriexec_file() when doing the lookup.

a copy might make sense though

[sjg]

sys/security/mac_veriexec/veriexec_metadata.c

141–142

Hmm that appears to be a merge botch or something, the free call is still there in our tree.

This is an old patch that I need to revisit anyway given the delay since it was posted.