LWN.net Logo

Distributions for the Nexus 7 (TGDaily and HotHardware)

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 16:15 UTC (Wed) by ibukanov (subscriber, #3942)
Parent article: Distributions for the Nexus 7 (TGDaily and HotHardware)

All those so-called real Linux projects that target tablets are inherently less secure than Android. Android was designed from the ground to run untrusted applications. This is just impossible with X11 applications unless one starts to use one x-server per application.


(Log in to post comments)

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 16:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

nice FUD (yes, X11 is a security issue), it goes well with the repeated statements that I'm seeing from security experts that iOS is more secure than Android

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 16:53 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

What FUD? The fact that on a desktop Linux all applications have access to all the files by other applications because they run under the same uid of logged in user? Or that one X11 client can grab all input from another? Or that a user have no simple way to affirm that a prompt asking for a password by a terminal application is really the prompt by that application?

And BTW, thanks for a nice try to bring irrelevant iOS discussion.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 18:21 UTC (Wed) by hummassa (subscriber, #307) [Link]

The "private files" thing can be bypassed (using the "same uid" on the manifest, or setting up doc sharing between the apps).

And it's not really practical in a desktop/laptop (or in a more "complete" tablet): it is common to share files between unexpected sets of applications in more complete workflows.

But, that being said, it's perfectly possible to replicate the "one uid per app/set of apps" thing on desktop linux.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 19:52 UTC (Wed) by ibukanov (subscriber, #3942) [Link]

> The "private files" thing can be bypassed (using the "same uid" on the manifest, or setting up doc sharing between the apps).

Yes, there are issues with Android, but at least it is base architecture is sound and does allow to run untrusted or unverified code while common Linux distributions is in worse shape now in that area than Windows 8.

> And it's not really practical in a desktop/laptop (or in a more "complete" tablet):

It is a matter of proper GUI. I am typing this in a VM running on qubes-os.org which allows a secure way to share files between VMs. There are some annoyances, but they comes from the fact that the only IMO reasonable way to isolate the current desktop Linux apps is to put them into separate VMs. That of cause wastes a lot of resources and requires high-end laptop. It would be nice to have the security without the need for VMs, but I just do not see how with the current desktop API this is feasible.

> it's perfectly possible to replicate the "one uid per app/set of apps" thing on desktop linux.

Yet this is not available now while Android is around for over 5 years. So I do not see as useful all those efforts to optimize desktop Linux model for tablets rather than fix Android to allow to run the desktop Linux apps without breaking the sandbox.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 20:08 UTC (Wed) by shmerl (guest, #65921) [Link]

Android is not fixable in many other fundamental ways, so I don't see at as a future for mobile Linux.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 26, 2012 20:55 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

What ways?

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 0:38 UTC (Thu) by shmerl (guest, #65921) [Link]

Like inferior libc (bionic vs glibc).

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 1:27 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

We've argued about it in the past:
1) There are no _fundamental_ deficiencies in bionic. Mostly some not-yet-implemented stuff.
2) You can still use glibc (with some difficulty) and uClibc (without much less problems) on Android.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 4:37 UTC (Thu) by shmerl (guest, #65921) [Link]

And after discussions it came out, that bionic isn't going to improve, because upstream doesn't want to accept those fixes. So why bother. There are normal systems with better libc. And security can be built as needed.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 4:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Wrong. It came out that upstream is not particularly _interested_ in these fixes. That doesn't mean it'll forever stay this way - most fixes are trivial.

>There are normal systems with better libc. And security can be built as needed.
And they are?...

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 6:03 UTC (Thu) by shmerl (guest, #65921) [Link]

Not interested [to improve themselves] and not accepting the fixes - is not the same. Not accepting means preventing the improvement. It's better to work with those who collaborate for improvement, instead of overcoming some resistance for no real reason, and coming up with weird workarounds, when effort can be spent straight on positive things.

Any normal Linux with glibc is already without these problems.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 8:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Wrong. "Not accepting" in Android right now means "we are too busy with really important stuff".

Which is justifiable, because nobody really cares about iconv() or some kind of exotic xsdstradfhdup function in bionic. Instead Google concentrates on really important stuff, the stuff that allows them to achieve 1.5M activations every single day.

If they really need that shit from glibc (which is by far the shittiest library in a standard Linux stack) then it'll be added in a minute.

> Any normal Linux with glibc is already without these problems.
Yeah sure. And that why Android is already about 20x bigger than all Linux desktop systems that ever existed.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 17:08 UTC (Thu) by shmerl (guest, #65921) [Link]

You seem to care about politics and who is bigger. I care about technology and what is technically better. We have different interests.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 28, 2012 23:49 UTC (Fri) by bronson (subscriber, #4806) [Link]

You seem to have ignored "which is by far the shittiest library..." That's a technical argument.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Shmerl is aware of my technical objections.

I think that glibc (and generally all libcs) are designed by a band of idiots that should not be allowed EVER to come close to a computing device.

For example, glibc requires a metric ton of additional stuff like locales and timezones. And all this shit can't even be used! For example:
1) There's no way to get the next time for DST transition. Too complex? I can do this just fine in .NET.
2) There's no way to simply get the time in another timezone without modifying a hidden global variable!
3) Ditto for localization - it only works to make regexes like [A-Z] fail in Estonian locale (because Z is not the last letter in Estonian alphabet). But normalizing a string for a given locale without modifying a global variable? No can do.
4) There's dependency on NSS that makes it impossible to install glibc without raping the whole OS. And what for? Only to make a couple functions like getpwent() work. And of course, this functionality is insufficient for a lot of real-world tasks, like searching a list of by a prefix. Do you see a pattern here?

uclibc and bionic made the right decision - to jettison all that crap and instead build a lean and mean libc.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>like searching a list of by a prefix
Correction: "like searching a list of users in a huge LDAP directory by a prefix".

glibc

Posted Dec 30, 2012 7:57 UTC (Sun) by jrn (subscriber, #64214) [Link]

I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?

I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.

glibc

Posted Dec 30, 2012 8:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> I'll bite. What does "normalize a string for a given locale" mean? Are you referring to case folding or something?
For example, convert string to a title case in en_ZA locale while the system locale is es_ES.

> I think the band of idiots you are referring to is called the POSIX standards committee. Though I like their work and don't consider them to be a band of idiots.
Yup. The sheer amount of idiotic decisions in POSIX made it irrelevant long time ago. Almost all real software has to rely on various kinds of extensions.

Oh, by "irrelevant" I mean that POSIX compliance is not even worth the time spent to read POSIX spec.

glibc

Posted Dec 30, 2012 8:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> For example, convert string to a title case in en_ZA locale while the system locale is es_ES.
Or even a better example, convert the string "is this true" to upper case to uppercase in en_US with tr_TR locale. We got hit with this "bug" _several_ time.

The other way around is also hilarious.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:54 UTC (Fri) by nix (subscriber, #2304) [Link]

So... your entire body of complaints regarding glibc being 'by far the shittiest library in a standard Linux stack' relates to localization? And, in particular, relates to glibc not providing various admittedly useful localization functions?

These functions are not provided for a single simple reason -- they are not required to implement the POSIX API: random extensions really shouldn't be thrown into glibc, because they have to be maintained forever (yes, yes, strfry() shouldn't be there, but it dates from a time when glibc was much younger and development was much wilder -- and now it cannot be removed). The localization databases and the like are required to implement that API (including things like the localization support in printf()). This is doubly true for the timezone stuff which is really there only so that conversions to the local timezone for filesystem stuff works.

What mystifies me is that you suggest that this problem is resolved by, uh, using bionic et al, which don't implement *any* of the POSIX-mandated localization stuff *at all* and thus may break real applications that depend on the existence of this support. Surely this leaves you even worse off than glibc does? At least (in the new glibc governance world) these problems are potentially resolvable? You can't add proper localization to bionic at *all* without adding all the features that glibc already has, then adding more on top of that.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 19:53 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>So... your entire body of complaints regarding glibc being 'by far the shittiest library in a standard Linux stack' relates to localization?
Also:
1) Inability to use statically linked glibc or bundled glibc.
2) Inability to use latter versions of glibc to create binaries for earlier versions. So I'm forced to install a parallel chrooted system so that my binaries compiled on a recent Ubuntu can be started on RHEL.
3) Fairly slow malloc implementation.
4) Huge size for embedded systems and inability to create a cutdown version.
5) Dependency on runtime-loadable modules (NSS).
...

But yeah, the design of localization and time handling is just an iconic example.

>These functions are not provided for a single simple reason -- they are not required to implement the POSIX API.
And so freaking what? Create a separate 'lib-shitfulled-POSIX-compatible abomination-c' and be done with that. Then continue developing a sane successor.

Most developers don't care about POSIX at all (which is good).

> What mystifies me is that you suggest that this problem is resolved by, uh, using bionic et al, which don't implement *any* of the POSIX-mandated localization stuff *at all* and thus may break real applications that depend on the existence of this support.
Good. Any application that depends on glibc for localization is broken.

>Surely this leaves you even worse off than glibc does?
No, it's actually much better solution. I can bundle bionic (or uClibc) and my favorite localization library along with my application.

> You can't add proper localization to bionic at *all* without adding all the features that glibc already has, then adding more on top of that.
Yes, I realize that glibc can't be modularized at this point. But it can at least be made _useful_ by including obvious extension functions. They even (gasp!) can later be standardized.

But noooo, POSIX is a sacred cow and everybody should bow down before it.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 0:25 UTC (Sat) by khim (subscriber, #9252) [Link]

I care about technology and what is technically better.

Do you care about ability to use it for anything practical or not? That's critical question.

There are people who are doing things like Haiku: things which are technically interesting and challenging but which are not used by Joe Average and will never be used by Joe Average. Eventually they end up in some kinda VM and show “the possible alternate world” for the future generations.

And then there are practically useful things: for these you need popularity. Because technical problems can be fixed (Windows is prime example: Windows 3.0 was popular but highly unstable while Windows 7 is extremely stable and relatively secureз… more secure then Linux in some circumstances), but they can only be fixed when you have enough developers and you only have enough developers when your system is popular.

Systems which ignore “cheap popularity” and concentrate on “technical soundness” usually migrate from the second camp to the first one. Some developers accept and embrace such transitions (witness HURD), but some suddenly start caring about popularity at some point… but usually it's way too late then. *BSD are prime example: long time ago they stopped trying to win popularity contests and concentrated on “doing things right” (there are many ways to define what the “right” thing is—that's why we have many different versions of BSD). And they had huge headstart (when FreeBSD and NetBSD were already quite complete and useful systems Linux was a joke). Today they all are struggling to survive.

Note that this process is so acute today exactly because all these supposedly snobby Linux-only projects are struggling to survive, too: they are in similar race—but with Android instead. History repeats itself: Android started as something toy-like (from POV of “traditional” GNU/Linux), but it improves extremely fast (although not always in the direction people from traditional GNU/Linux background like) and it's easy to imagine world where in 5-10 years “traditional” GNU/Linux based desktop will be where *BSDs are today.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 18:43 UTC (Fri) by nix (subscriber, #2304) [Link]

glibc (which is by far the shittiest library in a standard Linux stack)
Evidence? Oh, that's right, you don't have any, because this assertion is ludicrous. Yes, glibc is baroque and somewhat overcomplicated and is notably bad at a few use cases (such as those requiring static linking), but it is robust, reliable, flexible, remarkably complete, has an exceedingly stable API and ABI, and just works under an enormous variety of pressures and loads on a larger number of machines than anything else in the desktop Linux stack bar the kernel itself.

It is not by any measure 'by far the shittiest library in a standard Linux stack'. That goes far past hyperbole into outright untruth. You should apologise to the glibc developers.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 9:58 UTC (Sat) by foka (subscriber, #6707) [Link]

On the contrary, I see that the Bionic maintainers are indeed improving Bionic, in their own ways. For example, I find their effort in getting Android's bionic C library back in sync with upstream both encouraging and commendable.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 7:30 UTC (Thu) by rsidd (subscriber, #2582) [Link]

I assume this is a problem if you want to install untrusted apps -- but if the idea is that you'll use a distro, as desktop linux users do, why is it less secure than desktop Linux?

Yes, Amazon Kindle, Skype and other proprietary apps (if they appear for tablet linux) cannot be trusted and may not be avoidable for most users. And they can read all your files. But they can already do that on desktop linux.

Also, I'm not sure about this:

This is just impossible with X11 applications unless one starts to use one x-server per application.
The X server can allow display from all local users (applications), and each application can run in its own UID.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 8:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

X server has probably more security holes than an average colander. Nobody really cared about inter-application isolation until very recently, and it shows.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 21:26 UTC (Thu) by Wol (guest, #4433) [Link]

Actually, unfortunately, I think nobody with any power (in other words, commit access) actually cared about X at all!

Which is why when Xorg was born, EVERYBODY (near enough) switched in a hearbeat. At last, we had an X which was run by people who *did* care.

And, much as i'm scared about the idea, which is why X is on course to be replaced by Wayland. (Which is *designed* to be capable of doing everything X can do. A lot of important things seem to be being ignored, because nobody seems to care enough to do anything about them :-(

Cheers,
Wol

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 28, 2012 9:38 UTC (Fri) by renox (subscriber, #23785) [Link]

> Which is *designed* to be capable of doing everything X can do.

This sentence isn't very good..
At a high level it is somewhat true, as Wayland is a part of the GUI frameworks and the GUIs won't really change in the end, but Wayland is very different from X, two examples (there are more):
1) Wayland clients don't know where their window are displayed on a screen, X clients do.
2) with X you can send a glyph cache to the remote X server and use this to display efficiently text, with Wayland (alone) you can't do this, you're supposed to render the text locally then send a big image of the result to the server.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 16:56 UTC (Sat) by Wol (guest, #4433) [Link]

To which I have to respond (and I'm not a Wayland developer, so this is very much aiui)

1) And why do they need to know? That's the job of the display manager or whatever it is. "need to know" is important, and knowing stuff that is totally unnecessary makes things too complicated.

2) That sounds like you're running X over Wayland or vice versa. At the moment I don't think you can run Wayland remotely, but aiui there is nothing that prevents the Wayland communication layer from talking over a network. So there is nothing (in principle, in practice the software hasn't been written) stopping your program sending a message "write this text here" that then gets sent over the network to a remote render engine.

(Given the fact that Rob Landley (the X guy who cares) is actively working to help Wayland make X obsolete, I can't see that they would have designed it so such things couldn't be done ...)

Cheers,
Wol

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 17:28 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

unless there are two Rob Landley's, I think you have the wrong person

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 30, 2012 21:03 UTC (Sun) by Wol (guest, #4433) [Link]

Quite possibly. Who was the guy who got thrown out of XFree for trying to improve X?

Cheers,
Wol

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 30, 2012 21:18 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Keith Packard

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 1, 2013 18:10 UTC (Tue) by Wol (guest, #4433) [Link]

Yup. I meant him. Sorry...

Cheers,
Wol

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 20:48 UTC (Sat) by renox (subscriber, #23785) [Link]

For (1) It may matter or not depending on the situation, that is still an important change.

For (2) this won't prevent network transparency, just use more bandwith in some situations, so I doubt they'll make such big change to Wayland's design for this.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 19:04 UTC (Fri) by nix (subscriber, #2304) [Link]

Actually the performance effect of sending big bitmaps over the network rather than 'write this text here' is devastating: you can go from thousands of lines scrolled per second to one line or even less.

But it was finally pounded into my head that fixing this in Wayland is the job of a toolkit remoting library (hopefully one single library used by lots of toolkits), which can easily tell what text the application wants to render. This isn't fundamentally harder than having network transparency in the server, though I fear it will lead to massive inconsistency as different toolkits choose to do transparency in different ways :(((

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 4, 2013 20:12 UTC (Fri) by renox (subscriber, #23785) [Link]

> Actually the performance effect of sending big bitmaps over the network rather than 'write this text here' is devastating: you can go from thousands of lines scrolled per second to one line or even less.

Especially on a WAN yes.

> But it was finally pounded into my head that fixing this in Wayland is the job of a toolkit remoting library (hopefully one single library used by lots of toolkits), which can easily tell what text the application wants to render. This isn't fundamentally harder than having network transparency in the server, though I fear it will lead to massive inconsistency as different toolkits choose to do transparency in different ways :(((

The other being that no such remoting library is implemented and the reduced remote performances that you described.

Which is why I disagreed with the sentence '[Wayland] is *designed* to be capable of doing everything X can do.'..

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 5, 2013 16:22 UTC (Sat) by paulj (subscriber, #341) [Link]

All the major toolkits (GTK+, Qt, WxWidgets, any others?) *ALREADY* support a remote rendering protocol that works with Wayland: X11. Via either Xlib or XCB.

Note that the situation of multiple /libraries/ for remote rendering *already* exists today for X11 without Wayland. Note further that several toolkits (GTK+ and Qt) *already* supported multiple rendering outputs (framebuffer, X11), and even multiple *remote* output protocols (X11, HTML5 in at least the case of GTK+) prior to Wayland and the sky did not fall in.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Jan 5, 2013 17:48 UTC (Sat) by nix (subscriber, #2304) [Link]

I was sort of assuming that the intent was to eventually deprecate X11, and that all the damning of X11 for horrible remote performance meant that it wasn't a suitable remoting protocol.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 10:47 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

> I assume this is a problem if you want to install untrusted apps -- but if the idea is that you'll use a distro, as desktop linux users do, why is it less secure than desktop Linux?

Surely a distribution provides some level of trust, but even Debian may not provide all the necessary packages. For example, recently just to compile some stuff I had to download random packages (and trust that they are OK) from at least 3 different servers. Plus using a distribution offers no defense against bugs in applications that connects to network that can be exploited. And a bug in a browser allows to take the whole desktop.

> Yes, Amazon Kindle, Skype and other proprietary apps (if they appear for tablet linux) cannot be trusted and may not be avoidable for most users. And they can read all your files. But they can already do that on desktop linux.

Barring bugs on Android Skype cannot read passwords and other private data for other applications.

> The X server can allow display from all local users (applications), and each application can run in its own UID.

From http://lwn.net/Articles/517375/ - X11 provides isolation only between users, not between applications run by the same user.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 11:50 UTC (Thu) by rsidd (subscriber, #2582) [Link]

> The X server can allow display from all local users (applications), and each application can run in its own UID.

From http://lwn.net/Articles/517375/ - X11 provides isolation only between users, not between applications run by the same user.
I was suggesting the Android model where each application is run as a separate user, but displays to the same X server.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 12:59 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

> I was suggesting the Android model where each application is run as a separate user, but displays to the same X server.

One of the points of that article is that X does not provide isolation between its clients. It does not matter if they are run from the same user id or come from different computers. As long as applications share X-server, they can do bad things with each other. Fixing this requires so many changes to the X protocol that one better starts with scratch.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 27, 2012 17:12 UTC (Thu) by shmerl (guest, #65921) [Link]

What precludes Wayland to work differently though and have better process isolation? X is a transitory state in the mobile and desktop Linux. Wayland is the next big step.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 28, 2012 14:57 UTC (Fri) by renox (subscriber, #23785) [Link]

> What precludes Wayland to work differently though and have better process isolation?

Nothing and there are already a few discussions about how to ensure that Wayland is secure.

Distributions for the Nexus 7 (TGDaily and HotHardware)

Posted Dec 29, 2012 8:42 UTC (Sat) by rqosa (subscriber, #24136) [Link]

> As long as applications share X-server, they can do bad things with each other.

It's possible to run separate X servers in separate virtual consoles, though (this is how the "switch user" feature is implemented).

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