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