I have scenarios where I have to run cpuset to free certain core(s) and then schedule a process to run there.
As someone that doesn't use sudo or doas, intentionally not having auto-escalation abilities for the wheel user, I had been pondering about doing what's not to be done, changing attributes of /bin/cpuset from
to
, disabling anyone who isn't in wheel of actually running the command.
If this could be done via MAC module I would appreciate some config sample to do it...ofc I want to run cpuset-as-root only as my driving user, it should grant no other privileges.
My "hack" would get overwritten by pkgbase upgrade so I would have to reapply it - it doesn't matter that much.
Is there any realistic security impact for a single user workstation? Any kind of rogue code running as the user in wheel, is catastrophic, primarily for the data on the computer...owning the kernel solely servicing a single user seat is not really that beneficial, and it would imply cpuset has exploitable bugs, which latest AI cybersecurity work hasn't revealed. So the worst case is DoSing the system via cpuset by an actor that already has control the user account hence the user is already under the water anyway.
As someone that doesn't use sudo or doas, intentionally not having auto-escalation abilities for the wheel user, I had been pondering about doing what's not to be done, changing attributes of /bin/cpuset from
Code:
-r-xr-xr-x
Code:
-r-sr-xr--If this could be done via MAC module I would appreciate some config sample to do it...ofc I want to run cpuset-as-root only as my driving user, it should grant no other privileges.
My "hack" would get overwritten by pkgbase upgrade so I would have to reapply it - it doesn't matter that much.
Is there any realistic security impact for a single user workstation? Any kind of rogue code running as the user in wheel, is catastrophic, primarily for the data on the computer...owning the kernel solely servicing a single user seat is not really that beneficial, and it would imply cpuset has exploitable bugs, which latest AI cybersecurity work hasn't revealed. So the worst case is DoSing the system via cpuset by an actor that already has control the user account hence the user is already under the water anyway.
