[apparmor] Updating the Pidgin profile

Seth Arnold seth.arnold at canonical.com
Tue Jan 14 23:09:53 UTC 2014


On Tue, Jan 14, 2014 at 06:16:42PM +0100, intrigeri wrote:
> confining Pidgin is a top-priority for Tails, so I've been looking
> into it to see what profile I'll integrate into the
> apparmor-profiles-extra Debian package.
> 
> The Pidgin profile in lp:~apparmor-dev/apparmor-profiles/master hasn't
> changed since 11.04. I somewhat doubt that anyone has even tried using
> it with a recent Pidgin.
> 
> Since about two years, I've been locally maintaining and using another
> Pidgin profile. It may be too liberal in various aspects (and I'm
> happy to hear about it, reviews are more than welcome!), but at least
> it is up-to-date and works fine on current Debian unstable.
> I'm attaching it in its current state.
> 
> The diff is quite large (better use --ignore-space-change, as the
> profile on Launchpad uses tab indentation, contrary to all other
> profiles I've seen).
> 
> What would be the next steps towards merging my changes?
> 
> Should I split my changes into incremental commits? Does it seem crazy
> to un-bitrot the profile all at once, after I do the changes that
> a serious review will no doubt ask for?

I'd be fine un-bit-rotting the profile in one go, it seems unlikely to me
that we'd ever need to perform a bisection search on pidgin profile
changes. :)

A few comments inline

> # vim:syntax=apparmor
> 
> #include <tunables/global>
> 
> /usr/bin/pidgin {
>   #include <abstractions/audio>

The audio landscape has changed drastically since this abstraction was
written. There are parts of the audio abstraction that today should
probably be set aside as audio-hardware and made available for pulseaudio
and jackd and esd, and there are portions that should probably be made
available for audio applications.

Of course we don't have to solve this today, but it seemed worth
mentioning.

>   #include <abstractions/aspell>
>   #include <abstractions/base>
>   #include <abstractions/bash>
>   #include <abstractions/consoles>

Is consoles still necessary?

(And hrm, none of the lines in there have 'owner' prefixed.. oof.)

>   #include <abstractions/dbus>
>   #include <abstractions/dbus-session>
>   #include <abstractions/fonts>
>   #include <abstractions/freedesktop.org>
>   #include <abstractions/gnome>

gnome already includes fonts, freedesktop.org, user-tmp, and X
abstractions.

>   #include <abstractions/launchpad-integration>
>   #include <abstractions/nameservice>
>   #include <abstractions/private-files-strict>
>   #include <abstractions/ubuntu-browsers>
>   #include <abstractions/ubuntu-console-browsers>
>   #include <abstractions/user-download>
>   #include <abstractions/user-tmp>
>   #include <abstractions/ibus>
>   #include <abstractions/X>
> 
>   deny capability sys_ptrace,
> 
>   deny @{HOME}/.bash* rw,
>   deny @{HOME}/.cshrc rw,
>   deny @{HOME}/.profile rw,
>   deny @{HOME}/.zshrc rw,
> 
>   owner @{HOME}/.cache/dconf/user rw,
>   owner @{HOME}/.config/dconf/user r,

This reminds me I need to spend more time getting re-acquainted with
dconf...

>   owner @{HOME}/.config/enchant/ rw,
>   owner @{HOME}/.config/enchant/* rwk,
>   owner @{HOME}/.local/share/icons/ r,
>   owner @{HOME}/.local/share/mime/* r,
>   owner @{HOME}/.gnome2/nautilus-sendto/** rw,

Oof, what's this do? :)

>   owner @{HOME}/.gstreamer*/ rw,
>   owner @{HOME}/.gstreamer*/** rw,

.. And this?

>   owner @{HOME}/.pulse/ rw,
>   owner @{HOME}/.pulse/** rw,

Is this as wide-open as I think it is?

>   owner @{HOME}/.pulse-cookie rwk,
>   owner @{HOME}/.purple/ rw,
>   owner @{HOME}/.purple/** rwk,
> 
>   /bin/dash rix,
> 
>   /{dev,run}/shm/ r,
>   /{dev,run}/shm/* rw,
> 
>   /etc/ r,
>   /etc/pulse/client.conf r,
>   /etc/ssl/certs/ r,
>   /etc/ssl/certs/** r,
>   /etc/ssl/certs/ssl-cert-snakeoil.pem r,
> 
>   owner /tmp/orbit-*/* w,
>   owner /tmp/pulse-*/* w,
> 
>   /usr/bin/gconftool-2 rix,
>   /usr/bin/gnome-default-applications-properties ix,
>   /usr/bin/gnome-network-preferences ix,
>   /usr/bin/gnome-open rmix,
>   /usr/bin/gsettings rix,
>   /usr/bin/pidgin r,
>   /usr/bin/xdg-open rmix,
>   /bin/which rix,
>   /usr/bin/gvfs-open rmix,
> 
>   /usr/share/glib-2.0/schemas/gschemas.compiled r,
> 
>   /usr/lib/ r,
>   /usr/lib/frei0r-1/*.so rm,
>   /usr/lib/libvisual-*/**.so rm,
>   /usr/lib/pidgin/*.so rm,
>   /usr/lib/purple*/*.so rm,
> 
>   /usr/share/ca-certificates/*/** r,
>   /usr/share/enchant/enchant.ordering r,
>   /usr/share/locale-langpack/** rm,
>   /usr/share/purple/ca-certs/ r,
>   /usr/share/purple/ca-certs/** r,
>   /usr/share/myspell/dicts/ r,
>   /usr/share/myspell/dicts/** r,
>   /usr/share/tcltk/** r,
> 
>   /usr/share/themes/ r,
>   /usr/share/themes/** r,
> 
>   /usr/share/hunspell/ r,
>   /usr/share/hunspell/** r,
> 
>   deny @{PROC}/** r,

Hrm, I believe glibc uses different proc files to determine magic malloc
sizes and other internal variables. I'm curious what exactly is being
denied?

>   # Site-specific additions and overrides. See local/README for details.
>   #include <local/usr.bin.pidgin>
> }

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140114/306b2b77/attachment-0001.pgp>


More information about the AppArmor mailing list