The sanitized_helper profile is designed to be as generic as possible to
make it work with most binaries when a more restrictive profile is
unavailable.
As you pointed out, this approach raises several concerns:
- The security level of this profile is only slightly above unconfined, which
can undermine the security level of profiles using them.
- This profile can give a false sense of security.
- In most cases, a more restrictive profile could be applied one without
breakage.
To address these concerns, we can either :
(1) Create variants of this profile tailored for different scenarios.
(2) Stack this profile to a more restrictive one when possible.
(3) Retain the profile as-is, using it only as a last resort.
IMO, the first option is the most practical short-term solution, as it
could reduce risks with only a limited effort.
For instance, slightly more restricted variants could include:
- Slightly more restrictive files rules (include
<abstractions/private-files-strict>)
- Deny writes on known executable locations ( e.g.
/{,usr/,usr/local/}{sbin,bin}/*)
- Denying network access when not needed by not using “network inet,”
Obviously, these rules cannot work for all helpers, thus using these
variants would require testing in order to avoid breakages, but I guess
that could be a first step.
Additionally, when a profile exists specifically for a binary (evince,
firefox, …) , we should use it directly, and not rely on this generic
profile (or stack both)?
The long term solution remains to create tight profiles for all known
binaries, but we are definitely not there yet.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2102694
Title:
dangerous "sanitized_helper" contains /** rwkl,
Status in apparmor package in Ubuntu:
New
Bug description:
abstractions/ubuntu-helpers's sanitized_helper which was a Pandora box
from from its inception.
It contains:
```
network inet, # line 42
/** rwkl, # line 88
/usr/{,local/}lib*/{,**/}* Pixr, # line 58
```
what basically means : "stop using apparmor" and access any file on my
filesystem and more than enough to cause *grave* damages. (write-mode to
everything)
The first comment in the profile says: "lenient profile when 'Ux' is desired"
and also says:
> LP: #851986 until AppArmor utilizes proper environment filtering
But ... LP: #851986 is "Won't fix" ... since 2012.
Last but not least, more and more programs were made to transition to this
almost-Ux mode.
~150 in a default modern installation, namely:
akregator
alpine
amarok
anjal
apport-bug
apturl
ark
arora
audacious2
audacity
azureus
balsa
bangarang
banshee
banshee-1
bitstormlite
btmaketorrentgui
chromium{,-browser}
citadel
clamscan
claws-mail
cone
debconf-communicate
decibel
deluge{,-gtk,-console}
digikam
dillo
dolphin
Dooble
dragon
dvipdfm
dvipdfmx
elinks
elmo
emacsclient.emacs2[2-9]
emacsclient.emacs-snapshot
emacs-snapshot-gtk
eog
epiphany
epiphany-browser
epiphany-webkit
esperanza
evince
evolution
exaile
file-roller
firefox
freevo
geary
gedit
gimp*
gmerlin
gmplayer
gnome-appearance-properties
gnome-btdownload
gnome-gmail
gnome-mplayer
gwenview
gxmms
gxmms2
hornsey
iceweasel
jlgui
juk
kaffeine
kate
kazehakase
kde4-config
kde-open
kget
kmail
kmplayer
konqueror
krusader
ktorrent
leafpad
libreoffice
liferea-add-feed
links
listen
localc
lodraw
loimpress
lowriter
lpr
lpstat
lynx.cur
mailody
midori
mktexpk
mktextfm
modest
mousepad
mplayer
muine
mutt
nautilus
nautilus-sendto
netrik
netsurf
okular
oocalc
oodraw
ooffice
ooimpress
oowriter
opera
pcmanfm
plasma-browser-integration-host
potamus
promoe
qbittorrent
qmmp
quodlibet
rhythmbox
scim
scim-bridge
seamonkey
shotwell
smplayer
strange-quark
swfdec-player
sylpheed
thunar
thunderbird
timidity
tkrat
totem
totem-gstreamer
totem-xine
transmission{,-gtk,-qt,-cli}
{t,T}hunar
vim.gnome
vlc
w3m
xarchiver
xdg-open
xfmedia
xmms
yelp
/opt/brave.com/brave{,-beta,-dev,-nightly}/brave-browser{,-beta,-dev,-nightly}
/opt/google/chrome{,-beta,-unstable}/google-chrome{,-beta,-unstable}
/usr/lib{,64}/chromium{,-browser}/chromium{,-browser}
/usr/lib{,64}/firefox*/firefox*
/usr/lib/fennec-*/fennec
/usr/lib/GNUstep/Applications/GNUMail.app/GNUMail
/usr/lib/icecat-*/icecat
/usr/lib/iceweasel/iceweasel
/usr/lib/libreoffice/program/soffice
/usr/lib/mozilla/kmozillahelper
/usr/lib/@{multiarch}/libproxy/*/pxgsettings
/usr/lib/openoffice/program/soffice
/usr/lib/thunderbird*/thunderbird{,.sh,-bin}
/usr/share/minirok/minirok.py
/usr/share/software-center/software-center
Pinch me if you can't find a way to do hidden & automated arbitrary file
access and network exfiltration using one of these (Actually more than one good
candidate for such an attack)
As commented in #1042771, some of these do have their own profile
(evince/LibreOffice) but are set to run uncontrolled anyway.
To summarize: Tons of insecure programs are knowingly granted uncontrolled
permissions (full fs access + full network access + executing arbitrary
programs in /usr/{,local/}lib*/{,**/}*
No actual reason is given (the same program, for being called a
"helper", becomes trusted and Ux-friendly) and no resolution is even
being considered (2012 "Won't fix") and it's been so since at least
one decade.
The very minimum fix is that to comment these by default:
network inet, # line 42
/usr/{,local/}lib*/{,**/}* Pixr, # line 58
and this
/** rwkl, # line 88
should be adapted to something a bit more reasonable like
@{XDG_CACHE_HOME} & @{XDG_DOWNLOAD_DIR} & /tmp
(And LP #1042771 should fine a resolution so that less programs depends on
`sanitized_helper` (even less LoC monsters like LibreOffice or firefox)
Finally, note that unless I'm mistaken, `abstractions/ubuntu-helpers` stating
`usr/bin/firefox Cxr -> sanitized_helper` (to take one example), means that
launching firefox from totem or any media-players makes it run unconfined,
meanwhile it is when ran directly from the user. This sounds absurd and a
serious hole in the apparmor security model.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2102694/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
