Bug 486975
Summary: | kernel: Unable to write to file as non-root user with setuid and setgid bit set | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Eugene Teo (Security Response) <eteo> |
Component: | kernel | Assignee: | Cong Wang <amwang> |
Status: | CLOSED ERRATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 5.4 | CC: | dhoward, dzickus, esandeen, jpirko, jtluka, lwang, mjwalker, pbenas, rkhan, sathishpy, syeghiay, vgoyal, vmayatsk |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-30 07:09:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Eugene Teo (Security Response)
2009-02-23 14:49:33 UTC
It doesn't seem like a *security* issue to me; it's denying an action, not granting an action we expect to be denied. Eugene, do you concur? Anyway, specifically here in inode_change_ok(): /* Make sure a caller can chmod. */ if (ia_valid & ATTR_MODE) { if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER)) goto error; we are trying to change the mode (due to the suid stripping) but we don't have perms to do that. On the notrunc write path, we call file_remove_suid(), which sets the ATTR_FORCE flag and we are therefore able to remove the suid bits & continue. I think perhaps do_truncate() should also be just calling file_remove_suid(). I'll check into this upstream (same behavior there, FWIW) Thanks, -Eric Yep, with that change it works as (I think) it should: [root@inode ~]# ls -l /newdir/ total 0 -rwsrwsrwx 1 root root 0 2009-02-23 15:57 file1 [root@inode ~]# su newuser [newuser@inode root]$ dd if=/dev/zero of=/newdir/file1 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000641472 s, 798 kB/s [newuser@inode root]$ ls -l /newdir/ total 4 -rwxrwxrwx 1 root root 512 2009-02-23 16:17 file1 (In reply to comment #3) > It doesn't seem like a *security* issue to me; it's denying an action, not > granting an action we expect to be denied. Eugene, do you concur? I concur. I'm opening this bug so that this can be dealt with as a normal bug. Thanks Eric! Proposed patch: http://patchwork.kernel.org/patch/32338/ FYI: The final version: http://lkml.org/lkml/2009/8/19/5. Already merged into James' tree. in kernel-2.6.18-170.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified. Bug state changed from ON_QA to VERIRIED. $ cat do-my-test #!/bin/sh mkdir /newdir touch /newdir/file1 chmod 06777 /newdir/file1 useradd newuser su newuser -c 'dd if=/dev/null of=/newdir/file1' [root@dell-pe2850-01 486975]# uname -r 2.6.18-169.el5 [root@dell-pe2850-01 486975]# make run chmod a+x ./runtest.sh ./do-my-test ./runtest.sh /mnt/tests/kernel/errata/5.5/486975/do-my-test Running ./do-my-test As root: dd: opening `/newdir/file1': Operation not permitted ...finished running ./do-my-test, exit code=1 /kernel/errata/5.5/486975 result: FAIL Log: /tmp/tmp.fl3750 [root@dell-pe2850-01 486975]# uname -r 2.6.18-170.el5 [root@dell-pe2850-01 486975]# make run chmod a+x ./runtest.sh ./do-my-test ./runtest.sh /mnt/tests/kernel/errata/5.5/486975/do-my-test Running ./do-my-test As root: 0+0 records in 0+0 records out 0 bytes (0 B) copied, 1.9e-05 seconds, 0.0 kB/s ...finished running ./do-my-test, exit code=0 /kernel/errata/5.5/486975 result: PASS Log: /tmp/tmp.oe3263 DMesg: /tmp/dmesg.log An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0178.html |