LD_PRELOAD work in progress

[Jamie Strandboge]

On 02/25/2015 09:51 AM, Stéphane Graber wrote:

> The problem on our side is "easy to maintain" as we presumably don't
> want people building systems relying on a completely outdated kernel
> that's full of security holes, so that'd essentially boil down to
> maintaining every kernel from 3.4 to 4.0 and that seems pretty
> unrealistic to me.
> 
So we took a very firm stand in Cape Town and it has softened since then AFAICT
(others can comment more fully). Basically, we want people to use the officially
supported Ubuntu kernel for official builds/devices/etc, however for people just
getting started with snappy we've found that people want to use their current
kernel to kick the tires and we've seen that a lot already AIUI. I guess people
are thinking that backporting AppArmor is easier than moving to Ubuntu's kernel
(I don't have insight as to why). As for Android kernels, that is a something
we'll have to keep in mind until manufacturers start using our kernel and we
drop the android layer. Maybe if we raise the backpoting bar so high that no one
would ever want to use an earlier kernel, all our problems will be solved!
</half-joke>

> For a 3.4 kernel, I expect we at the very least need to backport:
>  - Current AppArmor (which doesn't fit any definition of small)

Do note, this has already been done many times and the porting guide has fairly
reasonable instructions on how to do it, and AppArmor is pretty much
self-contained (unlike overlayfs). We went as far back as 3.0 for maguro (though
it was slightly less self-contained).

...

> And then we've mentioned using user namespaces down the line to add an
> extra layer of security for applications which need to think they're
> root or need to own some privileged resources but do not require real
> root. To support that, we'd have to backport a few hundred patches from
> the 3.13 kernel.
> 
This has been mentioned but we've decided to not pursue this at this time.
...

> I just want to make sure we won't be compromising the security of that
> new platform because of Android's inability to keep up with current
> supported kernel version.
> It may be that the answer to that is to mark those devices as "tainted",
> run without the new fancy security features and fallback on slow
> alternative (like FUSE). Which would also mean that any such "tainted"
> device wouldn't be able to access paid content as we can't possibly make
> any security guarantee to the app author.

Let me assure you, the last thing I want to do is compromise security. :) I
don't think overlayfs is inherently more secure than everything else-- the idea
of using overlayfs was born from the idea of supporting multiple frameworks and
reusing existing debs from the archive-- not for security reasons. Overlayfs is
convenient in a number of ways, but adds also complexity, so there is a
tradeoff. Is it worth it? Not sure yet, but I'm glad the conversation has
expanded to more people so we can be sure we make the right choice.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150225/e93dd5bd/attachment.pgp>