desktop-packages team mailing list archive

[Hadmut Danisch <hadmut@xxxxxxxxxx>]

Jamie,

Am 07.12.2011 um 15:31 schrieb Jamie Strandboge:

> Hadmut, we have been through this before--

Yes. And I would highly appreciate if you'd remember that last time I
finally won because of the better arguments.

You could save your and my valuable time if you wouldn't start the same
discussion over and over again, and recall previous results and
improvements instead.



> Ubuntu is a general purpose
> distribution and we cannot deny access to all files in the manner you
> keep suggesting because people will just turn off apparmor altogether


And you're repeating the same mistake again and again. 

As usual you totally missed the point and closed the bug before you
understood it.


I don't ask you to make apparmor config more tight. I totally agree with you that it should remain in a state where it works for the non-experts. 


I ask you to split it in two parts. The part that does not need user configuration (i.e. to read /usr/lib and such things needed to get the software up and running), and the other part that opens multimedia files at runtime, because that's the part that security-aware users might modify to match their individual needs. 

BTW., that's exactly the reason why I put both bug reports into one,
because I hoped it would help understanding why there is need to split
that in two separate files.

On one hand, the parts depending on the operating system (like /udev,
/usr/lib,...) which is the same on all machines, should not be modified
manually because once modified the debian/ubuntu package system refuses
(or at least has problems) to upgrade files in /etc/... So there's no
clean and smooth way to configure security to local needs without beeing
cut from updates and bug fixes (like the one with the /udev thing).

But if you were splitting that in a general part and a separate part
describing the run time access rules (like $HOME/** ), one could
configure the latter without touching the former and thus still get all
updates with new packages.


The last time when we had the same problem with a different package, it
was a lot of hard work and took me a heap of ugly swear words to
convince the ubuntu crew. Why is that so difficult to understand and why
do I have to explain that from scratch again and again?


Why is it that difficult to understand that I do not ask you to make ubuntu more tight, but to split the configuration into two parts to allow users to make it more tight if they want without breaking the package updates?


Why the hell do you force people to break updates if they want more than
just zero security?


Hadmut

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evince in Ubuntu.
https://bugs.launchpad.net/bugs/900324

Title:
  apparmor profile provides too much access

Status in “evince” package in Ubuntu:
  Won't Fix

Bug description:
  Hi,

  evince comes with apparmor profiles.

  
  1) The profiles are incomplete/outdated. Kernel keeps complaining because evince tries to read from udev which has been moved to /run/udev by some ubuntu berserks: 

  Dec  5 16:10:19 sodom kernel: [24711.331270] type=1400
  audit(1323097819.959:148): apparmor="DENIED" operation="open"
  parent=22723 profile="/usr/bin/evince" name="/run/udev/data/b253:6"
  pid=23251 comm="evince" requested_mask="r" denied_mask="r" fsuid=1000
  ouid=0

  
  2) The profiles are mostly useless because the open almost everything for read/write anyway, e.g. 

    @{HOME}/** rw,

  
  What's the point in having a apparmor profile if it opens all doors? The idea of apparmor is to restrict particular access, not to open everything to make it run like without an apparmor profile. 

  BTW, the file design is poor. The master profile should contain only
  what evince needs to run (like /usr/lib... and such things) and not
  intermix with the files to read or write for working. These options
  should be put into a separate file to allow the admin to modify it to
  local needs without breaking the upgrade process for the main part of
  the profile.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: evince-common 3.2.1-0ubuntu2
  ProcVersionSignature: Error: [Errno 2] Datei oder Verzeichnis nicht gefunden: '/proc/version_signature'
  Uname: Linux 3.2.0-030200rc2-generic x86_64
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  Date: Mon Dec  5 16:14:31 2011
  EcryptfsInUse: Yes
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
  PackageArchitecture: all
  ProcEnviron:
   PATH=(custom, user)
   LANG=de_DE.UTF-8
   SHELL=/bin/tcsh
  SourcePackage: evince
  UpgradeStatus: Upgraded to oneiric on 2011-10-29 (36 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/900324/+subscriptions