Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5.9
-
None
-
RHEL 8; MariaDB upstream RPMs
MariaDB-server-10.5.9-1.el8.x86_64
Description
The directory
/usr/lib64/mysql/plugin/auth_pam_tool_dir
|
and the SUID-to-root binary
/usr/lib64/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
|
do not have correct permissions.
(While they do work, it is IMO not an ideal setup)
The current permissions are:
directory mysql:root 700
binary root:root 4755
The directory permissions allows an unprivileged user 'mysql' to tamper with the SUID-to-root binary inside the directory.
In general, all SUID-to-someone binaries / scripts should be ony changeable by the someone.
Following facts should be taken in consideration:
1/
Normally, files not specific to a certain user should be owned by a root:root with a desired permissions.
If the goal was to restrict access to the directory for the 'mysql' user exclusively, the ideal configuration would be: root:mysql 750
2/
If the binary can't be accessed by other users, such other users won't be able to use the PAMv2 server plugin when running their own server.
(e.g. when calling the mysqld directly with all of the needed arguments pointing to somewhere in their home dir )
Is such use-case expected or supported ?
I guess no one complained yet, so the more restrictive approach is probably fine.
3/
I'd say it would be more expected to have the desired restrictions applied on the binary itself, rather than the directory only.
It IMO express better the fact that the issue is with the binary itself.
There is probably no need to have the restriction on both the directory and the binary.
Conclusion:
If restriction to other users was NOT intended, I'd go with:
directory root:root 755
binary root:root 4755
(none restricted)
Else if restriction was intended, I'd go preferably with:
directory root:root 755
binary root:mysql 4750
(only the binary restricted)
Or
directory root:mysql 750
binary root:mysql 4750
(both the directory and the binary restricted)
Rather than:
directory root:mysql 750
binary root:root 4755
(only the directory restricted)
But NOT the current:
directory mysql:root 700
binary root:root 4755
(only the directory wrongly restricted)
What is the opinion of @otto as for Debian packaging ?
(or @Otto or @Otto Kekäläinen or @Otto_Kekäläinen or @OttoKekäläinen ... never figured out how to properly mention somenone in here ...)
While we are talking about PAMv2 plugin, I agree that MDEV-23628 might deserve a better error message.
Attachments
Activity
Status in Debian packaging:
find /usr/lib/mysql/plugin/auth_pam_tool_dir/ -ls
|
12198 0 drwx------ 1 mysql root /usr/lib/mysql/plugin/auth_pam_tool_dir/
|
12199 16 -rwsr-xr-x 1 root root /usr/lib/mysql/plugin/auth_pam_tool_dir/auth_pam_tool
|
My original suggestion was to have this auth pam tool as a separate plugin to limit the consequences of a potential vulnerability to only those systems that have it installed (99% of systems don't use this at all). After discussion with Serg it was decided to keep it by default (as the plugin size is so small) but I rewrote and documented it better in https://github.com/MariaDB/server/blob/10.6/debian/mariadb-server-10.6.postinst#L137-L154
Going with ` rwsr-x-- 1 root mysql /usr/lib/mysql/plugin/auth_pam_tool` would probably suffice.
However, let's think about this a bit and not do hasty changes.
or to restrict to mysql user and not have write permissions on directory:
directory mysql:mysql 500
binary root:mysql 4750
Thank you for the explanation Sergei.
Now that I see the problematic, I understand that my proposal is (mostly) wrong.
it will need to think it more through.
I agree that we surely shouldn't be hasty about it, just as Otto says.
Taking any permission from the file / directory owner does not add much security, as the owner can always change all of the permissions on his files.
It might be a slight more complexity added, as the 'mysql' user probably can't run shell and 'chmod' commands easily, but once in the state it can, it would only be security through obscurity. (Not necessarily bad IMO, just explaining)
I stumbled upon this issue when introducing PAMv2 plugin to RHEL.
During the security review of the newly introduced SUID-to-root binary.
I opened this ticket in a hope we can come to some universal upstream solution. It might not be the case for now, but the discussion already broaden my horizons.
I solved the issue the best I could for now on the downstream side.
I set following permissions:
directory root:root 755
binary root:mysql 4750
(only the binary restricted)
It felt more appropriate to set 'mysql' group for the binary itself, rather than for the directory, from the packaging POV.
And I moved the PAM plugins and files to a separate sub-package "mariadb-pam", which is suggested by the server ( = NOT installed by default with the server)
This way I am decreasing the number of people having the problematic code installed to a minimum.
The issue with anyone (else) in 'mysql' group having unrestricted access to the binary remain unsolved, yet minimised - I believe.
Isn't there any timeout, implemented in PAM (or the unix_chkpwd), which would slow down the attacker?
It is a common way to slow down brute-force attacks, implementing some sleep time before the credentials are evaluated.
100ms sleep is nothing for human, yet tremendous slowdown fot the brute-force attacker.
Can you clarify the main problem you're solving here:
The directory permissions allows an unprivileged user 'mysql' to tamper with the SUID-to-root binary inside the directory.
Tamper how? What can a mysql user do? A user can rename or delete it, losing suid rights. I don't see how a user can modify it to get additional access under suid.
Otto: My original suggestion was to have this auth pam tool as a separate plugin to limit the consequences of a potential vulnerability to only those systems that have it installed (99% of systems don't use this at all). After discussion with Serg it was decided to keep it by default (as the plugin size is so small)
It seems Fedora now went ahead and split this into a separate plugin. Maybe we should follow suit in upstream RPM packaging and in upstream/downstream Debian packaging as well? Having many different versions of a solution for the same problem can cause excess overhead and more problems.
https://src.fedoraproject.org/rpms/mariadb/c/51cd6d3ae2be8c6fc5b495238569107cd3eb2b67?branch=rawhide
The goal is to have a suid-root binary that only mysql user can execute.
It is very intentional that other users should not be able to access it, otherwise they would be able to use it to brute-force passwords.
You suggest to limit the access to mysql group, not to mysql user. I'm unsure of consequences, if it would potentially allow more users to run the tool, it would allow them to brute-force OS passwords. Who can have access to mysql group, some admin performing a backup?
otto, FYI