Page MenuHomeFreeBSD

mac_grantbylabel focused priv escallation via maclabel
Needs ReviewPublic

Authored by sjg on Nov 24 2020, 10:46 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 25 2024, 6:12 AM
Unknown Object (File)
Dec 20 2023, 4:21 AM
Unknown Object (File)
Dec 12 2023, 6:49 PM
Unknown Object (File)
Oct 13 2023, 5:44 PM
Unknown Object (File)
Sep 6 2023, 4:12 AM
Unknown Object (File)
Aug 19 2023, 11:47 PM
Unknown Object (File)
Aug 14 2023, 1:05 PM
Unknown Object (File)
Jul 7 2023, 6:17 PM

Details

Reviewers
stevek
emaste
Summary

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

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

sjg requested review of this revision.Nov 24 2020, 10:46 PM

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

revert change to veriexec_fingerprint.c

sebastien.bini_stormshield.eu added inline comments.
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
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

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.