This module leverages labels set via mac_veriexec
to provide priv escallation to specific applictaions.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
No Test Coverage - Build Status
Buildable 35021 Build 32006: arc lint + arc unit
Event Timeline
| lib/libveriexec/exec_script.c | ||
|---|---|---|
| 117 | 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? | |
| 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? | |
| lib/libveriexec/exec_script.c | ||
|---|---|---|
| 117 | I thnk there are some updates to mac_veriexec needed - in our tree it calls | |
| 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 | |
| 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. | |