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@xxxxxxxxxxx> wrote: > > On Thu, 07.11.13 20:09, Miloslav Trmač (mitr@xxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
