Permissions of /usr/bin/su, /usr/bin/newgrp, and /usr/bin/mount
Hello,
I've been searching the forums and net and couldn't really find the answer to this question. I'm running CentOS 7 and cPanel 11.64.0.24. I see other people have had this issue, I'm trying to understand how it happened though.
I'm running rkhunter and it complains about three files having file permissions that are different than what RPM expects. Those three files and their current permissions and what their expected permissions are listed below:
With /usr/bin/su, the expected owner and group is root:root, but the real owner is root:wheel. Are these changes that cPanel implemented for security reasons? I don't really understand why mount and newgrp have been modified. I can't really see Linode doing this without saying something. Thanks!
FILE REAL PERMISSIONS EXPECTED PERMISSIONS
=============== ================ ====================
/usr/bin/su 04750 04755
/usr/bin/newgrp 0755 04755
/usr/bin/mount 0755 04755
With /usr/bin/su, the expected owner and group is root:root, but the real owner is root:wheel. Are these changes that cPanel implemented for security reasons? I don't really understand why mount and newgrp have been modified. I can't really see Linode doing this without saying something. Thanks!
-
Hello, I can confirm the permissions and ownership values you referenced (under the "Real Permissions" column in your post) match what's on my CentOS 7 (with a stock kernel) test system with cPanel. You may want to review the "/scripts/secureit" file to get a better idea of what this script does: cat /scripts/secureit
Additionally, you can view the cPanel installation log at /var/log/cpanel-install.log to see if permissions or ownership values were modified for a specific file. Thank you.0 -
Hello, I can confirm the permissions and ownership values you referenced (under the "Real Permissions" column in your post) match what's on my CentOS 7 (with a stock kernel) test system with cPanel. You may want to review the "/scripts/secureit" file to get a better idea of what this script does:
cat /scripts/secureit
Additionally, you can view the cPanel installation log at /var/log/cpanel-install.log to see if permissions or ownership values were modified for a specific file. Thank you.
Thanks! /script/secureit was what modified the permissions. I restored the various packages using yum, just until I could figure out what happened. Now that I figured out what happened, I tried to run /script/secureit in order to "secure" the files, but it's not working. This is the output that I get:[root@franklin ~]# /scripts/secureit Finding set[gu]id files via find /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. /usr/bin/find: warning: you are using `-perm +MODE'. The interpretation of `-perm +omode' changed in findutils-4.5.11. The syntax `-perm +omode' was removed in findutils-4.5.12, in favour of `-perm /omode'. [root@franklin ~]# ls -l /usr/bin/su /usr/bin/newgrp /usr/bin/mount -rwsr-xr-x 1 root root 44232 Apr 12 16:43 /usr/bin/mount -rwsr-xr-x 1 root root 41776 Nov 5 2016 /usr/bin/newgrp -rwsr-xr-x 1 root root 32096 Apr 12 16:43 /usr/bin/su [root@franklin ~]# stat /usr/bin/su /usr/bin/newgrp /usr/bin/mount File: "/usr/bin/su" Size: 32096 Blocks: 64 IO Block: 4096 regular file Device: 800h/2048d Inode: 3141 Links: 1 Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-06-17 12:00:32.655332221 -0400 Modify: 2017-04-12 16:43:52.000000000 -0400 Change: 2017-06-16 11:03:58.621243010 -0400 Birth: - File: "/usr/bin/newgrp" Size: 41776 Blocks: 88 IO Block: 4096 regular file Device: 800h/2048d Inode: 3090 Links: 1 Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-06-17 12:00:32.425331492 -0400 Modify: 2016-11-05 16:17:10.000000000 -0400 Change: 2017-06-16 11:04:24.854659503 -0400 Birth: - File: "/usr/bin/mount" Size: 44232 Blocks: 88 IO Block: 4096 regular file Device: 800h/2048d Inode: 3126 Links: 1 Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-06-17 12:00:31.815329559 -0400 Modify: 2017-04-12 16:43:52.000000000 -0400 Change: 2017-06-16 11:03:58.604576291 -0400 Birth: -
I can manually change the bitmasks for the files, but I think the secureit script might not be working properly. I even tried with the --fast parameter, which did remove the setuid bits from /usr/bin/mount and /usr/bin/newgrp. It didn't change the group for /usr/bin/su from root to wheel though. I thought there was an option under WHM but I cannot find it now. So I ran /usr/local/cpanel/bin/taskrun, which changed the /usr/bin/su group from root to wheel.... Anyway, just wanted to let you know I think the /scripts/secureit script might not be functioning as it was intended to function. I believe to get the script to function properly, it should check if findutils is equal or greater to version 4.5.12 and if so, it should use find -perm /omode instead of find -perm +omode or perhaps just find -perm omode (for the new behaviour). Thanks!0 -
Hello, Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look and determine if that's the intended behavior. You can post the ticket number here so we can update this thread with the outcome. Thank you. 0 -
Hello, Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look and determine if that's the intended behavior. You can post the ticket number here so we can update this thread with the outcome. Thank you.
Okay, but now that the setuid bits are removed, it might be hard to test. Maybe I should readd the S bit to some files so they can verify the /scripts/secureit script doesn't remove them, unless the --fast command line option is applied.0
Please sign in to leave a comment.
Comments
4 comments