ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 01/16/2014 08:16 PM, Steve Langasek wrote:
> Hi all,
> 
> Many thanks to Chris for raising this important topic.
> 
> As Alex mentioned, he and I had chatted earlier this week about the
> importance of keeping a single Ubuntu root image that's common to all
> devices.  This is something that we need to hold the line on; allowing
> individual OEMs to have custom root images - as opposed to having their
> device-specific logic in their device image - isn't scalable, and we need to
> ensure that anything that currently requires us to add device-specific logic
> to the rootfs is treated as a bug to be resolved.
> 
> Now, there's also an inevitable tension between the need to keep a single,
> device-independent rootfs, and the need to support arbitrary hardware on top
> of it.  Some of this should be addressed by providing well-defined interface
> hooks for the device image (just as we have already agreed to do for the
> carrier customization image).  In some cases, though, I think we should look
> closely at whether the per-device customizations should actually be allowed,
> or whether this is just an expedient solution that's going to cause us to
> pile up the technical debt down the line.  For instance, many of the
> per-device files included in the rootfs today are related to the use of
> non-standard, non-upstreamable kernel drivers.  I'm sure some of these will
> be necessary, but I don't know that it's a good idea to allow unbounded
> kernel driver divergence for production Ubuntu devices.  Should we actually
> need per-device udev and apparmor rules, or is this simply opening the door
> for us to repeat Android's mistakes?
> 
Honestly, I don't want per device apparmor rules at *all*-- I would rather have
apps access an out of process helper through a well defined interface, like what
we have now with pulseaudio. This is far easier to maintain and a better
security model-- apps can't attack the kernel device drivers directly. There are
two bugs that discuss this: LP: #1197133 and LP: #1197134. AIUI we will have
this per-device access in the short term for various things and would likely
have this at least for the midterm for at least graphics. Having it for just one
though (graphics), means that we may need per device apparmor rules.

...

>> and ship the apparmor device accesses as part of lxc-android-config, and
>> just have OEMs drop their udev rules in /usr/lib/lxc-android-config/ and
>> their apparmor device accesses in /usr/share/apparmor/hardware/....  The
>> porting guide[1] has language for modifying lxc-android-config for these
>> things already-- perhaps it should be updated to include instructions on
>> using the device tarball mechanism?
> 
> Is it reasonable to make /usr/share/apparmor/hardware a bind mount (or
> symlink) to /vendor/apparmor on the touch devices?
> 
Note, I don't really have a preference on the solution. That said, this is
slightly complicated because the profiles do things like this:

 #include "/usr/share/apparmor/hardware/graphics.d"
 #include "/usr/share/apparmor/hardware/audio.d"
 #include "/usr/share/apparmor/hardware/video.d"

If any of these subdirectories do not exist, then the profile will fail to load
and applications will fail to launch. As such, if we bind mount
/usr/share/apparmor/hardware to /vendor/apparmor, we need to make sure that
these directories all exist (though they can be empty):

 #include "/vendor/apparmor/hardware/graphics.d"
 #include "/vendor/apparmor/hardware/audio.d"
 #include "/vendor/apparmor/hardware/video.d"

With bind mounts, it also means that everything we do ship in
/usr/share/apparmor/hardware will be hidden, so the vendor would have to provide
all the hardware-specific policy, not just the bits and pieces they need for
their device. One way around this is to just have apparmor-easyprof-ubuntu also
ship /vendor/apparmor/hardware/{audio|graphics|video}.d as empty directories and
have the policy include those too. This is untidy for both non-touch systems and
for policy though.

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

Attachment: signature.asc
Description: OpenPGP digital signature