| |||||||||||||
The trouble with CAP_SYS_RAWIOThe trouble with CAP_SYS_RAWIOPosted Mar 13, 2013 20:11 UTC (Wed) by smurf (subscriber, #17840)In reply to: The trouble with CAP_SYS_RAWIO by cesarb Parent article: The trouble with CAP_SYS_RAWIO
No, the check should be
if (reading && !CAP_SYS_RAWIO) return -EPERM;
when the device is opened, and anything subsequent checking the file's flags.
(Log in to post comments)
The trouble with CAP_SYS_RAWIO Posted Mar 13, 2013 20:20 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Applications that drop CAP_SYS_COMPROMISE_KERNEL are still unable to write. How does this help?
The trouble with CAP_SYS_RAWIO Posted Mar 13, 2013 21:25 UTC (Wed) by khim (subscriber, #9252) [Link] Application which drops CAP_SYS_COMPROMISE_KERNEL will work just fine because both checks happen in open(2) syscall. It'll break application which opens file for reading and writing but then only issues read commands. This can be fixed by changing logic: if read/write open(2) request is attempted without CAP_SYS_COMPROMISE_KERNEL then it's silently translated to read-only open(2) request. Of course application which will try to write to said file will see EBADF which may crash it, but I'm not sure what can save such an application.
The trouble with CAP_SYS_RAWIO Posted Mar 13, 2013 21:38 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The current state of things: an application that drops all capabilities other than CAP_SYS_RAWIO can read and write MSRs. The new state of things: an application that drops all capabilities other than CAP_SYS_RAWIO can no longer write MSRs. So, how does that fix anything?
The trouble with CAP_SYS_RAWIO Posted Mar 13, 2013 22:40 UTC (Wed) by smurf (subscriber, #17840) [Link]
It fixes the "open the device and then drop privileges" usage.
It does not fix the "drop privileges and then open the device" case. I know that. But if userspace runs afoul of this problem, the fix is a simple re-ordering of two lines of code. Or retaining an additional capability.
Is there any real-world program that would run aground at this change, or is this an academic exercise?
Personally I never regarded CAP_SYS_RAWIO (or _ADMIN) as written in stone. It's a sufficiently broad catch-all category that a reasonable programmer should expect that requiring a different, or additional, capability for a task that used to work with only this one right might be in the cards.
The trouble with CAP_SYS_RAWIO Posted Mar 13, 2013 22:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
You've still broken userspace. It's still undesirable and it's still a fundamental problem with the capabilities interface. Similar changes in other places in the Fedora kernel have broken various bits of userspace in irritating ways.
The trouble with CAP_SYS_RAWIO Posted Mar 14, 2013 4:50 UTC (Thu) by heijo (guest, #88363) [Link]
The problem is that both CAP_SYS_RAWIO, CAP_SYS_ADMIN and possibly others used to be equivalent and imply the ability to arbitrarily alter the system.
Redefining those to no longer being able to do so is idiotic and breaks compatibility.
The trouble with CAP_SYS_RAWIO Posted Mar 14, 2013 5:04 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
CAP_SYS_RAWIO is not equivalent to CAP_SYS_ADMIN. That's why they're not defined to the same value. It does not imply the ability to arbitrarily alter the system. That's *the entire point* of capabilities.
The trouble with CAP_SYS_RAWIO Posted Mar 14, 2013 19:52 UTC (Thu) by WolfWings (subscriber, #56790) [Link]
Actually I don't believe the suggestion change (move the check for write-modes to the open()) breaks userspace. Not the 'silent downgrade to read-only' which is the entire problem right now and identical to the 'check on write()' problem.
Right now you don't appear to be able to drop-all-caps then open /dev/msr, you need to open it first then drop privs as there already is a check to block so much as reads unless you have the RAWIO cap.
So how does the "read = RAWIO, write = RAWIO && COMPROMISE" check on open() instead of on write() break userspace? Programs would be refused access to /dev/msr and complain about it, same as before, and their existing 'Check your caps!' error messages would still apply.
There's a difference between 'breaking' userspace in a way that existing apps error messages don't apply and may not even have error-handling paths for the new issues, and simply enforcing stronger checks in a way compatible with existing error handling.
The trouble with CAP_SYS_RAWIO Posted Mar 14, 2013 20:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
A program used to work. After a change, that program no longer works. A non-working program is broken. Breaking that program doesn't add any real additional security in the common (ie, non-Secure Boot) case, and so is undesirable.
The trouble with CAP_SYS_RAWIO Posted Mar 17, 2013 15:46 UTC (Sun) by mrjk (subscriber, #48482) [Link]
With the suggested change there would be no program that used to work that would not work now that I can see. Every single current program that worked with dropping privileges after an open would still work the exact same way with caching the new capability at open time and using the cached value on those opened channels.
Can you give an example that would now break -- that wouldn't have broken already?
The trouble with CAP_SYS_RAWIO Posted Mar 17, 2013 17:02 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Any application that drops all privileges other than CAP_SYS_RAWIO before attempting the open?
|
|||||||||||||