Re: Restricting / Limiting permission/ownership of targetted binaries?

On 4/26/21 10:20 AM, A. James Lewis wrote:
> It would make a lot of sense to include a hash of a known good version, 

> but in this case... there are many different machines of different 
> versions involved, and I do not know the specific hash of the binaries 
> in question... there may indeed be many different versions and they may 

> change when the application is patched.

Ya.

Keeping sudoers up to date with the different hashes can be a lot of effort.

Fortunately, my understanding is, that you can have the same path with 
multiple different hashes.  E.g. one hash that is pre-patch and another 
hash that is post patch.  So your sudoers will still function as desired 
before and after patching.  Obviously someone will need to care for and 
feed the sudoers file to account for such hashing.

> My problem is one of "too many cooks",... leading to a possibility that 

> permissions could be changed by someone who lacks understanding the 
> implications... and I want to ensure that sudo would cease to run the 
> command with escalated privilages, in the same way that sshd would cease 
> to allow logins based on "authorized_keys" if the permissions of that 
> file were insecure.

That can be a problem.

The other idea that I had was to create a wrapper script that is called 
which will check the permissions for you.  E.g. something that parses 
the output of namei -l on the real target, checking for allowed 
permissions and / or ownership to see if they are (one of a set of) 
allowed values; e.g. root and / or calling user.  Presuming that you use 
sudo to get to the proper user which can be matched in the script.

> Perhaps it is a feature that would be useful for others as well?....

I don't know.

It seems like it's an entirely new security model that hasn't existed in 
sudo up to this point.



-- 
Grant. . . .
unix || die

____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users