Startup Locks Down Mobile Linux (Dark Reading) [LWN.net]

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 26, 2007 10:44 UTC (Thu) by fergal (subscriber, #602) [Link]

Strategy #1 is just fine as long as you make the owner an "authority". I remember a story a while back about an x-ray machine that was locked down like this for safety but again, there's no reason not to give the private key for that machine to the owner of the machine.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 26, 2007 10:54 UTC (Thu) by zooko (subscriber, #2589) [Link]

You make a good point that Strategy #1 ("Prevent malicious or buggy code from running.") need not imply that the root authority is someone other than the owner of the machine.

However, regardless of who the root authority is, Strategy #1 will succeed at preventing malware only inasmuch as it centralizes the power of deciding which code gets to run. (And only inasmuch as the centralized powers -- Microsoft, Debian, etc., don't themselves screw up or get hacked.)

One shouldn't think that Strategy #1 ("Prevent malicious or buggy code from running."), in which the owner of the computer gets to be the one who approves or disapproves each piece of code that he will run, can simultaneously solve malware and prevent centralization of control.

Strategy #2 ("Allow code to run but prevent it from gaining authority that it shouldn't.") needs more attention. I don't like Strategy #1 because it *either* fails to prevent malware *or* it requires centralization of control over what software can be deployed and used (or some combination of both). I don't want either of those things.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 26, 2007 11:25 UTC (Thu) by fergal (subscriber, #602) [Link]

I think they're largely orthogonal. Whether my kernel is signed or not, I should be able to grant limited permissions to apps in a flexible way.

#1 allows you to detect "foreign" software running on your device (where "foreign" is decided by the key owner).

#2 allows you to prevent damage by software which trust, signed or unsigned.

#2 is desirable for downloaded applications but is no use for a downloaded firmware/kerne and yes, for most consumers, that doesn't matter.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 26, 2007 16:29 UTC (Thu) by sepreece (subscriber, #19270) [Link]

"Strategy #1 is just fine as long as you make the owner an "authority"."

Making the owner an authority is fine as long as the scope of that authority is the user's own device. The problem is that most of the interesting devices include a component that interacts with the outside world, and the operators and other users of networks tend to want to give the device little scope to screw things up for others.

That leaves you with approach 2 - limit what the software can do, so that even malicious changes cannot interfere with the operation of connected networks or services. The problem with applying that notion to Linux is that in non-virtualized environments, it's very hard to limit the scope of the software that has control over all the routes to the outside world.

The solution may be separation of functions - using separate hardware modules or virtualization to protect some aspects of the device from even the kernel (which ends up not having all the actual hardware privileges it may think it has).

Of course, the end result may be more expensive devices with only limited additional scope for owner modification (because the interesting functionality may be in the parts that are walled off in sepsrate hardware or separate OS environments).

Personally, I would have no problem with code that I wrote being Tivo-ized, as long as the changes were shared. I am comfortable with devices being sold as devices, for a specific purpose, rather than as general-purpose computers, especially if it lowers the device cost. I also believe that people who do object should be free to license their code so that it is not used in such ways.

However, since the GPL is the primary license for the community, I wish that the FSF had made this an optional restriction, so we could share the rest of the license improvements and have a consistent interpretation of everything else in the license, rather than increasing ambiguity and making the divide larger than it needed to be.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 26, 2007 18:54 UTC (Thu) by anonymous1 (guest, #41963) [Link]

> code that I wrote being Tivo-ized, ..... especially if it
> lowers the device cost

I wonder how can the manufacturer keeping control lower the cost of a device? If anything the encryption and digital signature should increase the cost. The sales price might be cheaper for a Tivoized device, but that is because of subsidies from the manufacturer, a subsidy given to take away freedom of the end user. Be it Tivo, or be it cell phone companies and locked cell iPhone's, the principal is the same.

> I wish that the FSF had made this an optional restriction
One can still choose to license under GPLv3 and give additional permission, that they are not bound by the Tivoization clause.

Projects give exceptions when they feel the need to, CUPS is a good example. Drivers written for CUPS and Apple OS dont have to follow GPL. Linux Kernel modules can be proprietary (ok this is controversial, but almost standard industry practice), because of exception given by some kernel developers, and the general turning of a blind eye.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 27, 2007 1:47 UTC (Fri) by sepreece (subscriber, #19270) [Link]

The cost lowering is in comparison to protection strategies that rely on hardware separation. For mobile phones this usually means providing a separate chip or a separate core, sufficiently isolated that the modified application processor (the one running the GPL software) can only communicate with it in limited ways, typically using the modem-control (AT) protocol.

Most Linux-based phones in the market today have ssome separation, but insufficient to assure that the untrusted side can't affect hte operation of the trusted side. So, the added cost relative to today is for reengineering and hardware changes.

As to permissions versus restrictions, I would not choose to use an added permission because the GPLv3 allows added permissions to be removed downstream, which I would find unacceptable.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 27, 2007 2:43 UTC (Fri) by anonymous1 (guest, #41963) [Link]

I am not a fan of this spectrum regulation, so i dont like "trust"ed devices.
I would rather that I control the cell phone, and can then trust it.

>I would not choose to use an added permission because the GPLv3 allows added
> permissions to be removed downstream, which I would find unacceptable.

Not a practical problem. I think your concerns are overblown. Proprietary kernel modules have been with us for a long time, somebody could just fork the kernel and insist that closed modules are not OK. But it wont fly in the practical sense. As long as there are active communities, there exists moral leadership in those communities, and downstream people will in practice find it impossible to remove your permission or the kernel module exception.

I think that the differences in the community are not that important and we should just share code. I prefer giving my code under GPLv3 or later. But if somebody asks me to relicense bits and pieces of code to BSD, GPLv2 or other licenses I gladly would. In fact I am thinking of releasing my code with just 5 year copy-monopoly. After that its public domain.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 27, 2007 8:53 UTC (Fri) by sepreece (subscriber, #19270) [Link]

"I am not a fan of this spectrum regulation, so i dont like "trust"ed devices.
I would rather that I control the cell phone, and can then trust it."

I have occasionally had to place emergency calls (fortunately for my own people); the reliability of the network matters to me and to most people. More to the point, you won't be able to sell any device that doesn't pretty thoroughly isolate control of the RF, so it's a mostly moot point.

On your other points, I generally agree. Since the license already requires preserving the text describing the licensing, the added permissions probably are functionally permanent.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 27, 2007 20:08 UTC (Fri) by anonymous1 (guest, #41963) [Link]

> place emergency calls... the reliability of the network matters
of course it does, and free spectrum like free software will be more reliable. i dont own a cell phone, and have relied on the generosity of passer-by to help me.
as for the bad guys, they can today buy a radio and mess communication up. so this control does give us anything positive

>you won't be able to sell any device that doesn't pretty thoroughly isolate control of the RF
yeah.. the law is an ass. the cell phones companies and the broadcasting companies have too much power, and the law serves their interests..

Can even make it tricky for users to change root authority

Posted Jul 27, 2007 6:10 UTC (Fri) by emk (subscriber, #1128) [Link]

It's even acceptable to make the user do some geeky song-and-dance routine to load their own keys. You know: "Plug the device into your PC. Depress the button inside the battery compartment using a paper clip. Run the sync utility and select the 'Add Root Authority' menu item."

This prevents users from accidentally loading malware, while still providing them with their full freedoms.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Jul 30, 2007 12:39 UTC (Mon) by Baylink (subscriber, #755) [Link]

> Strategy #1 is just fine as long as you make the owner an "authority".

Ah yes, the "everyone's as smart and thoughtful as me" fallacy.

Cause this works so well for ZoneAlarm, or Spybot Teatimer, on the average Windows PC for the average civilian.

We *call* them civilians because they're not geeks, people.

Sure *we* should have control, if we flash our Geek License at the door, but the average grandma? No, probably not. Who issues those Geek Licenses, anyway?

Startup Locks Down Mobile Linux (Dark Reading)

Posted Aug 1, 2007 16:35 UTC (Wed) by fergal (subscriber, #602) [Link]

Your comments seem unrelated to my post. In the example of the x-ray machine I said you would give a key to the owner of the machine. That means that should they choose to, they can take full control of the software on the box. It does not in any way create the zone-alarm "this software is unsigned, should I install it yes/no?" scenario.

As someone in another post said, perhaps the owner would be able to set a jumper or hold down a key combo and send his keys to the device. While the "official authority" is still in business and providing good service, most users would just leave it as they got it.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Aug 1, 2007 16:43 UTC (Wed) by Baylink (subscriber, #755) [Link]

Work on your reading comprehension.

The liability coverage of the manufacturer of the X-ray machine in your example is priced based on the assumption that the end-user cannot modify the code or configuration in such a fashion as to make it substantially more dangerous to end-patients; count on it.

If that assumption is no longer true, they likely won't be able to sell it at all, cause they won't be able to carry liability.

That's *substantially* more orthogonal, though, than is my example, to the actual point at hand.

"Hoping" that most end users won't poke around at it is often not good enough.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Aug 1, 2007 17:08 UTC (Wed) by fergal (subscriber, #602) [Link]

I still don't see how zone-alarm has anything to do with my post.

As for the liability issue, would the manufacturer be liable if the hospital had incorrectly serviced a non-user-servicable part and as a result killed a patient? I don't think so. I also don't think the manufacturer would be liable for what happens when the user replaces the software with their own custom version. IANAL so maybe I'm wrong, feel free to point to a legal principle in your jurisdiction that make a legal argument

Either way, this liability argument does not apply to unlockable consumer appliances anymore than it would apply to current unlocked-from-day-one consumer appliances.

Startup Locks Down Mobile Linux (Dark Reading)

Posted Aug 1, 2007 17:19 UTC (Wed) by zlynx (subscriber, #2285) [Link]

There are limits to legal liability. I really doubt any court will award damages against the manufacturer because a client took a screwdriver to the box and replaced a few resistors with a "better design."

Put the software unlock key inside the box with a big yellow tag on it. It's then just as secure as the physical hardware, so same rules should apply.