On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer <misc(a)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(a)0pointer.de>
wrote:
> > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr(a)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/ApplicationConfinemen...
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?
Mirek
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
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct