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 ).
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