On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer <misc@xxxxxxxx> 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@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 ). 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
