Draft Product Description for Fedora Workstation

[Michael scherer]

On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote:
> On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr at volny.cz) wrote:
> >> Is there a technical reason why we can't use their packaging format,
> >> interpreting it with our technologies but staying compatible?
> >
> > Well, the most relevant bit is that they use apparmor for
> > sandboxing. Nobody else uses that.
> 
> Are the packages expected to ship their own apparmor policy?
> That would appear to be at odds with the idea of protecting against
> malicious packages.  If they aren't expected to ship their own, could
> we implement the same sandboxing policy using SELinux?
> (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
> will be using some higher-level "profile" format, not raw AppArmor.)

The whole plan is here :
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement

Looking at :
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest

I would say "no".

>From a quick look, some abstraction are quite apparmor specific, see the concept
of read_path, which is something we can hardly translate to selinux ( since
apparmor use path, while selinux use a 2 tier system with label assigned to
path, and then privileges assigned based on label ).

What we could do is to have a better abstraction that would be apparmor
and selinux comptaible. Since despites what Lennart claim, AppArmor is also
used by Opensuse. And I am sure people using smackd ( such as intel people ) would
be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific,
even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to
support it that well ).

> > And I don't think it is a good idea to use .deb as an image format.
> .deb is just an ar archive; if this were the only difference, it would
> not be worth fragmenting the ecosystem over IMHO.  (Especially if the
> GNOME apps alternative is a "compressed disk image", which saves disk
> space and costs extra CPU time and memory, making exactly the wrong
> tradeoff in most situations AFAICS.)

While I do not see any obvious problem into using deb, I do not think it will
bring much gain. It will matter for people managing the low level format,
ie few people. Reusing the manifests ( if it was doable ) would have yield much
more gain. 

-- 
Michael Scherer