User: Password:
Subscribe / Log in / New account

Calibre and setuid "works on every single linux distro"

Calibre and setuid "works on every single linux distro"

Posted Nov 4, 2011 18:54 UTC (Fri) by RogerOdle (subscriber, #60791)
Parent article: Calibre and setuid

I think that Linux needs to be cleaner distinguishing between system file space and user file space. I use Fedora. If I login to the desktop and install a USB memory stick, plug-n-play installs it under "/media" using, I believe, the user-space-file-system "fuse". When mounted, fuse declares that I am the owner of the device and I can unmount it at will. I do not need root privileges to do this.

The problem the Calibre has is not unique but is common to everyone who tries to use connected advanced technology to a Linux computer. This includes ebook readers, smart phones, and digital camera. As time goes by, we can expect the variety of embedded Linux devices to grow. Think of this scenario: You buy a new TV that has embedded Internet so you can watch streaming video. It has a bug and the seller has provided a mechanism for you to apply a patch via a USB connection to your laptop. If you can mount this device in user space then you can upgrade the TV without requiring root access to your computer.

I am an embedded system engineer and I know the risk of allowing user space application permission to modify hardware control registers. There are ways to deal with this at the hardware level which have not been used in personal computing devices like laptops or desktop computers. The most effective one that would apply to this situation is the process/userID aware memory-management-unit (MMU) which is starting to appear in safety-critical embedded designs. This tags each address space accessible by the CPU with which user or process is allowed to access it. Embedded systems use them to restrict control of devices to only those processes that are designated to control the particular devices. A rogue thread on these systems can not accidentally modify someone else's control registers.

How does this relate to this situation? In the current state of Linux, once you are recognized as root, you have access to anything, can modify anything without restriction (whether it makes sense or not). Nothing tells the system what your intentions are so the system can not protect you from doing stupid things. The Kernel does not have fine-grain control at the hardware level to allow access to only certain hardware at certain times. It can only decide it you may control hardware directly or not. If it decides that you can control hardware then you have access to all hardware without restriction.

It is not really possible to put the restrictions into the Kernel at this time because there is no uniform hardware architecture that would allow this to be done by establishing common policies. The mechanism might be put into place but it would have to be customised but each brand and model of hardware out there. (not gonna happen). These smart MMUs provide a mechanism that gives the system enough fine-grain control at the hardware level to make user space control of plug-in devices safe and practical. They can eliminate the need to be root in order to control a device.

(Log in to post comments)

Calibre and setuid "works on every single linux distro"

Posted Nov 6, 2011 22:45 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

The MMU developments of which you speak sound very useful for OS partitioning, but almost completely irrelevant to the problems "how do we safely handle automatic mounting of removable mass storage?" and "how do we safely let users connect to their e-book readers, mobile phones, etc?" - both of which are software-wetware problems which can be satisfactorily solved with an MMU no more sophisticated than that of a PDP-11.

It also doesn't help (from a relevance-of-MMU-sophistication standpoint) that you can't use an MMU to give a process access to a single USB peripheral. Nobody puts down more USB host controllers than they absolutely have to - especially when the SoC or the motherboard chipset has one built in - so from the point of view of the MMU, the entire USB device tree is a single resource.

Calibre and setuid "works on every single linux distro"

Posted Nov 7, 2011 14:18 UTC (Mon) by RogerOdle (subscriber, #60791) [Link]

I do not see how you can say it is irrelevant. In the present circumstance, there is no mechanism to protect hardware from rogue or malicious code. This mechanism can restrict drivers to controlling only those devices that they are intended for and prevent other code from accessing them at all.

As to the USB but being a single tree in the hardware. This assumes that the designer would not make separate USB trees in order to take advantage of the different MMU style. It make sense if one assumes that any external device is at the mercy of the user anyway so that it should be controllable by user space code and that internal devices may be essential to normal operation. In fact, from a safety perspective, it may be desirable to have external devices be exclusively controlled by user space code. For example, many systems incorporate the internal cameras and microphones as internal USB devices. There is an ongoing problem with malicious code using these to spy on the user. A mechanism that locks these particular devices out without otherwise disabling the USB subsystem would be useful.

You can not assume that the new MMUs are irrelevant by considering past designs for which security was an after thought. These are new designs in which support for security mechanisms is being built into the hardware adding new opportunities that were not there before.

Calibre and setuid "works on every single linux distro"

Posted Nov 7, 2011 19:18 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

If Malice's program has managed to get root on Bob's Linux environment, and part of that Linux environment (whether a driver built into the kernel, or a userspace program) is responsible for controlling the USB peripherals and authorizing requests for data from them, then she can just invoke the appropriate APIs for accessing the USB camera through "proper channels"; she doesn't need to access the USB host controller's registers. (And why would she want to? Dinking about with the USB host controller's registers would be a good way to make the system glitch in ways that induce Bob to do a clean install, at least temporarily cleansing Malice's program from the system.)

Now, if Bob is running a partitioning hypervisor (so that the Linux kernel is not absolute lord and master of his computer's MMU) with no software-based privesc bugs, and there are no privesc bugs in the underlying silicon, and the Linux partition doesn't have access to the USB host controller, then the partitioning-enhanced MMU has secured Bob's camera from Malice's programs. (Unless there's a channel for the Linux partition to send read and write requests to the partition that owns the USB host controller, in which case you're back to square one unless that partition can somehow detect that the Linux partition has been compromised - which seems likely to be a halting-complete task.)

So, unless there's something I've missed, I stand by my assertion: This is a software and wetware problem, and a fancier MMU is not really the hardware solution. (The sensible hardware solution is a physically-operable killswitch for the camera and microphone which can't be bypassed by software.)

Calibre and setuid "works on every single linux distro"

Posted Nov 7, 2011 19:53 UTC (Mon) by dlang (subscriber, #313) [Link]

or at the very least the OLPC solution, a LED physically wired to the camera and microphone so that when they get power the LED lights.

Calibre and setuid "works on every single linux distro"

Posted Nov 10, 2011 19:27 UTC (Thu) by jengelh (subscriber, #33263) [Link]

And then falls short because the manufacturer happened to allow changing the LED state from the kernel, or there's some other kind of hardware bug that could be exploited to not light the diode.

Calibre and setuid "works on every single linux distro"

Posted Nov 10, 2011 21:09 UTC (Thu) by dlang (subscriber, #313) [Link]

that is why I said a LED wired directly to the device in question. not something controlled by a processor.

the camera needs power to run, if you wire the LED to the power lead of the camera it will light up when the camera gets power.

yes you can have the LED fail, or a bad solder joint, but other than that there really isn't much that can go wrong with this (and there is no way that this could fail in a way where it lights for the user using the camera, but not for the attacker.

Calibre and setuid "works on every single linux distro"

Posted Nov 12, 2011 18:47 UTC (Sat) by dpotapov (guest, #46495) [Link]

The idea of fine-grain control may sound attractive in theory, but it is completely impractical. In theory, you can create a general-purpose kernel with fine-grain access, but in practice Coyotos is arguably the best attempt to implement this idea, and it is far from being finished, let alone to being widely adopted.

The real problem is not limitations of hardware (it is relatively easy to get around some hardware limitations by sacrificing some performance). If you want to a fine-grain system, you have to address the confused deputy problem, and it is extremely difficult to deal with in a general purpose OS. You can completely eliminate 'root', but then you will have something like 'System' on Windows, which being compromised as bad as 'root'.

Many people do not realize that granting any additional permission to regular users has a very serious security impact on the whole system. It is exactly what happened the Calibre's lead developer. He thought that granting an unprivileged user mount/unmount/eject anything is just a nice feature, but it is also turned out to be a security flaw.

I do not say that LSM or other methods to limit what process can do are not useful. However, typically they do not provide real isolation as it would be impractical, so it is more about mitigation certain attacks or at least making them more difficult. On the other hand, virtual machines provide usually very good isolation, but there is no fine-grain control. BTW, the fact that VMs turned out to be so useful for many users prompted hardware manufacture to provide "VT-support", which includes improvements to MMU as well. So once software engineers find something useful and practical, hardware will be improved to support this functionality better.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds