Draft Product Description for Fedora Workstation

[Michael Scherer]

Le vendredi 08 novembre 2013 à 21:24 +0100, Miloslav Trmač a écrit :
> On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer <misc at zarb.org> wrote:
> > 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 ).
> 
> Yes, that's one thing that we cannot (and shouldn't) support, but
> read_path is listed in the "Red-flagged for manual review (use should
> actively be discouraged with updates made to policy groups and
> templates)" section; is it likely to be frequently used?

I can imagine that for any application having some kind of private
database ( like a list of music file, save for games, or scoreboard, etc
), this would be used. So yeah, not much, but not that uncommon either
IMHO. 

But even on the others fields, there will be some issues like the need
to keep the policy in sync ( for policy_groups ), and the need to keep
the template in sync (as the system work by taking template to generate
the policy).  Keep in sync the content and the name.

It could be doable to adapt, but I am quite sure that sooner or later,
we will face problem to keep the SElinux and AppArmor policies in sync,
due to the difference of approach. I also expect that a conversion
wouldn't be straightforward due to different stacks, etc.

I do not really see that as a sustainable approach.
-- 
Michael Scherer