mac_veriexec : extend veriexec to control deletion (unlink) and move (rename_from and rename_to) on protected files #613
Conversation
…veriexec module on files by including new syscall hooks. This patch is inspired by NetBSD veriexec. Functions implemented : - mac\_veriexec\_vnode\_check\_unlink: Unlink on a file has been requested and requires validation. This function prohibits the deleting a protected file (or deleting one of these hard links, if any). - mac\_veriexec\_vnode\_check\_rename\_from: Rename the file has been requested and must be validated. This function controls the renaming of protected file - mac\_veriexec\_vnode\_check\_rename\_to: File overwrite rename has been requested and must be validated. This function prevent overwriting of a file protected (overwriting by mv command). The 3 fonctions together aim to control the 'removal' (via unlink) and the 'mv' on files protected by veriexec. The intention is to reach the functional level of NetBSD veriexec.
darklem
changed the title
|
Anything I should change/adapt to make it useful for FreeBSD ? |
|
On the surface, this looks good to my eye. I don't think the normal veriexec folks are on github that often, so I've sent an email off to them to get their attention. I don't know their github handles, or I'd @ them here. I should have done this when it came in, please accept my apologies for missing it at the time. |
|
Blocking rename looks fine, but blocking unlink would break our package system. |
Have you seen @sgerraty's suggestions? |
Sorry for the delay ! I just read this answer. Thank you! |
Thank you Simon. I will make a change and propose it asap. |
|
@sgerraty in your court: I think the changes look OK, but I'm no expert. |
|
@sgerraty in your court: I think the changes look OK, but I'm no expert.
My github fu is obviously lacking, I cannot find/see the new change.
|
|
@sgerraty, I add a sysctl to toggle the unlink optionally. Tell me if you think I should adapt or change something. |
|
On Thu, 09 Mar 2023 06:23:26 -0800, Darklem writes:
@sgerraty, I add a sysctl to toggle the unlink optionally. Tell me if you thin
k I should adapt or change something.
Thanks for that.
What I suggest is use a tunable (TUNABLE_INT_FETCH) and
use one of {block,guard,protect}_unlink as a better name than just
unlink,
Then in mac_veriexec_init we can decide whether to set
mpo_vnode_check_unlink or not based on that tunable.
That way we can avoid the overhead of the calls if they are going to do
nothing.
The tunable can be visible via systcl but should be read-only.
…--sjg
|
…gle unlink protection. Add the corresponding read-only sysctl
|
Hi @sgerraty, I made the modifications based on your last suggestion. I hope it will be fine. |
Functions implemented :
- mac_veriexec_vnode_check_unlink: Unlink on a file has been
requested and requires validation. This function prohibits the
deleting a protected file (or deleting one of these hard links, if
any).
- mac_veriexec_vnode_check_rename_from: Rename the file has been
requested and must be validated. This function controls the renaming
of protected file
- mac_veriexec_vnode_check_rename_to: File overwrite rename has been
requested and must be validated. This function prevent overwriting of
a file protected (overwriting by mv command).
The 3 fonctions together aim to control the 'removal' (via unlink) and
the 'mv' on files protected by veriexec. The intention is to reach the
functional level of NetBSD veriexec.
Add sysctl node security.mac.veriexec.unlink to toggle control on
syscall unlink.
Add tunable kernel variable security.mac.veriexec.block_unlink to toggle
unlink protection. Add the corresponding read-only sysctl.
[ tidied up commit message, trailing whitespace, long lines, { placement ]
Reviewed by: sjg, imp
Pull Request: #613
|
Landed in the tree. Had to do a number of style cleanups, mostly brace placements and > 80 columns (for future reference). If we'd not let this linger, or had a better style checking script, I'd have done one more round to get them fixed. |
I'm not sure how to do that after the fact. All we have in our repo is the email address in the commit message submitted here. If there is a way we can do that w/o a forced push, I'm happy to do so. |
I linked a second email to my account. It works now. Thank you :) |
|
We can add a .mailmap file mapping if you provide the appropriate entry. |
Thanks for the advice |
Functions implemented :
- mac_veriexec_vnode_check_unlink: Unlink on a file has been
requested and requires validation. This function prohibits the
deleting a protected file (or deleting one of these hard links, if
any).
- mac_veriexec_vnode_check_rename_from: Rename the file has been
requested and must be validated. This function controls the renaming
of protected file
- mac_veriexec_vnode_check_rename_to: File overwrite rename has been
requested and must be validated. This function prevent overwriting of
a file protected (overwriting by mv command).
The 3 fonctions together aim to control the 'removal' (via unlink) and
the 'mv' on files protected by veriexec. The intention is to reach the
functional level of NetBSD veriexec.
Add sysctl node security.mac.veriexec.unlink to toggle control on
syscall unlink.
Add tunable kernel variable security.mac.veriexec.block_unlink to toggle
unlink protection. Add the corresponding read-only sysctl.
[ tidied up commit message, trailing whitespace, long lines, { placement ]
Reviewed by: sjg, imp
Pull Request: freebsd/freebsd-src#613
This patch intend to elevate the level of protection provided by the veriexec module on files by including new syscall hooks. This patch is inspired by NetBSD veriexec.
Functions implemented :
The 3 fonctions together aim to control the 'removal' (via unlink) and the 'mv' on files protected by veriexec. The intention is to reach the functional level of NetBSD veriexec.