| |||||||||||||
Calibre and setuid "works on every single linux distro"Calibre and setuid "works on every single linux distro"Posted Nov 6, 2011 22:45 UTC (Sun) by mpr22 (subscriber, #60784)In reply to: Calibre and setuid "works on every single linux distro" by RogerOdle Parent article: Calibre and setuid
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.
(Log in to post comments)
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 (✭ supporter ✭, #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 (✭ supporter ✭, #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.
|
|||||||||||||