hplip_3.18.12+dfsg0-2~bpo9+1_source.changes ACCEPTED into stretch-backports
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 10 Dec 2018 20:33:28 +0100 Source: hplip Binary: hplip hplip-data printer-driver-postscript-hp hplip-gui hplip-doc hpijs-ppds printer-driver-hpijs printer-driver-hpcups libhpmud0 libhpmud-dev libsane-hpaio Architecture: source Version: 3.18.12+dfsg0-2~bpo9+1 Distribution: stretch-backports Urgency: medium Maintainer: Debian Printing Team Changed-By: Didier Raboud Description: hpijs-ppds - HP Linux Printing and Imaging - HPIJS PPD files hplip - HP Linux Printing and Imaging System (HPLIP) hplip-data - HP Linux Printing and Imaging - data files hplip-doc - HP Linux Printing and Imaging - documentation hplip-gui - HP Linux Printing and Imaging - GUI utilities (Qt-based) libhpmud-dev - HP Multi-Point Transport Driver (hpmud) development libraries libhpmud0 - HP Multi-Point Transport Driver (hpmud) run-time libraries libsane-hpaio - HP SANE backend for multi-function peripherals printer-driver-hpcups - HP Linux Printing and Imaging - CUPS Raster driver (hpcups) printer-driver-hpijs - HP Linux Printing and Imaging - printer driver (hpijs) printer-driver-postscript-hp - HP Printers PostScript Descriptions Closes: 886391 915623 916139 Changes: hplip (3.18.12+dfsg0-2~bpo9+1) stretch-backports; urgency=medium . * Rebuild for stretch-backports. . hplip (3.18.12+dfsg0-2) unstable; urgency=medium . * printer-driver-postscript-hp: Bump Breaks/Replaces against hplip (Closes: #916139) * Trim trailing whitespace * Re-export upstream signing key without extra signatures . hplip (3.18.12+dfsg0-1) unstable; urgency=medium . * New upstream version 3.18.12 * DFSG-repack: - Drop compiled locatedriver and prnt/plugins/*.so - Drop unlicensed files from tarball root - Remove compiled libImageProcessor i386 & amd64 shared libraries artifacts as they don't come with source . * d/copyright refresh * Demote printer-driver-postscript-hp's Depends on hplip to a Suggests (Closes: #915623) * Add patch: - Fix linking of libhpipp and the *ext python extensions (Closes: #886391) Checksums-Sha1: 74375baba0f35f3b7a827df207e55951ce121349 3028 hplip_3.18.12+dfsg0-2~bpo9+1.dsc 4d9bcd55d76ba9fcedab5bed6f3c2a9eb4138887 107644 hplip_3.18.12+dfsg0-2~bpo9+1.debian.tar.xz Checksums-Sha256: db7557bd48d4c83c8166a98ed21eeb7b93caa907c6887c2f1a9ae7702f300980 3028 hplip_3.18.12+dfsg0-2~bpo9+1.dsc 94e9ed8dfcfae50154236ba4764bcd83f3d833d1a2fda79f9cc24dc255a6651f 107644 hplip_3.18.12+dfsg0-2~bpo9+1.debian.tar.xz Files: c550ad651041824d68455601dd051281 3028 utils optional hplip_3.18.12+dfsg0-2~bpo9+1.dsc fb2f069536bcd5c73a55e9eb883adab7 107644 utils optional hplip_3.18.12+dfsg0-2~bpo9+1.debian.tar.xz -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEe+WPIRpjNw1/GSB7i8+nHsoWNFUFAlwbPY4ACgkQi8+nHsoW NFWtYgv/R02FSqbDSqKLTHTAqkJ9IpOPA8bLqhu1xrHPeO0m1HsefPlp8RbUxWcU P1n1k0mk4zAjrpZGfVtMb2o5dR4BH2cDKJU+cODMY1wpOOANhalrKMZ3ykhYiJdf wwkxf7Fl+oYz49dWIHOklPxtazooJbnNUez1TYZuAFaUMflKBC0TE0jiWfVSLafz sBF59BJ/5Y07P1twwK8RIauvzr+8v9oFdgsZ+IYgaFC0QetvWXaTUjt0sOmEnpET onY59KS651I8a55fUqTSaDID0qx+PcpvkmASVtKRaEQ7j9xu3hiytWqDo34QLLHy XikDckzT6XbVItDuf0Ckw18XNlQWGRuHhVRHruRgjIBe30izdjelEMNHXwZwuRWR ZFmGCMi3FZvr44b2phgSEHQ5Sh3B6p2bkcBp9HeJhwL8Sq/mQQlEEfQOV2/FW64f xZ46BSJvTNgftGubsKHH/F6htQCytMVyfKwCSRyAlWzSbaMp/AB+M3Ab2Utth8yH R6zH2s8e =7EY7 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of hplip_3.18.12+dfsg0-2~bpo9+1_source.changes
hplip_3.18.12+dfsg0-2~bpo9+1_source.changes uploaded successfully to localhost along with the files: hplip_3.18.12+dfsg0-2~bpo9+1.dsc hplip_3.18.12+dfsg0-2~bpo9+1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: cups-filters_1.21.6-1_source.changes ACCEPTED into unstable
Le mardi, 18 décembre 2018, 19.19:56 h CET Brian Potkin a écrit : > A very nice test page. Looks good in mupdf. Try it on a real printer, even better :-) All the credit goes to Ubuntu designers first though. I'm considering asking whoever gets to provide the default Debian desktop branding to also propose a branded Printer Test Page. Let's see in 2019! Cheers, OdyX
Bug#914370: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
On 12/16/18 6:05 AM, intrigeri wrote: > Hi, > > (+ AppArmor upstream mailing list as I don't feel sufficiently > knowledgeable to provide authoritative answers or guidance) > > Didier 'OdyX' Raboud: >> Le jeudi, 22 novembre 2018, 19.05:19 h CET deb...@dbwats.plus.com a écrit : >>> The AppArmor profile supplied with cupsd isn't much use against local >>> attackers, as it allows cupsd to create setuid binaries at paths it >>> can write to (e.g. under /etc/cups). Since cupsd is run as root by >>> default, these binaries can be setuid root. >>> >>> (…) >>> >>> In default installations /etc is not on a nosuid mount, so provided >>> that they have a suitable exploit, local attackers who are unconfined >>> but non-root can use cupsd to create a setuid binary, then run the >>> binary themselves to gain unconfined root privileges. This is a known issue with unconfined. I can say there are some changes coming that will help. With the setuid issue, and also with creating the setuid binaries. 1. profile attachments are going to gain additional ability around setuid. So it will be possible to create policy that can trap these type of execs. 2. policy will be picking up extended permission allowing it to control the creation of setuid/setguid files etc, so the cups profile will be able to block the creation of these files. I can't give a time line for when these will land but I can say they won't make 4.21 > > Right. AppArmor does a decent job at sandboxing individual processes > but it offers little protection against a group of processes, running > under different policies, that cooperate to escape their sandbox or > otherwise escalate their privileges. The shared bits of a Linux system > that various processes can access are simply too many to write > AppArmor policy that successfully protects against such attacks > without using other isolation techniques. This bug report exemplifies > this, one of these cooperating processes here being mostly unconfined > (local user with arbitrary code execution as non-root) while the other > runs as root under a rather loose AppArmor policy. > Indeed. AppArmor in its current form is not well suited to total system confinement. It can be done but there are limitations. Instead policy has focused on application confinement/sandboxing. If a local user is not trusted they should not be unconfined, unconfined was designed specifically so that apparmor would not alter standard system behavior for the unconfined application. It is possible to confine users (though harder than it should be atm) and still have application confinement However as intrigeri points out sharing at wrietable locations is currently problematic and one of the missing pieces that we need to land before apparmor can be effectively used >> @Intri: any insight in how to address this? > > First, sorry for the delay, I've had less time than usual for Debian > recently. Thankfully I'm now back! :) > > tl;dr: AFAICT this is a known AppArmor limitation and there's nothing > we can do about it as long as cupsd runs as root (I assume we would > already be running it under a non-privileged user if that was easily > doable). > Policy can be adjusted to include trap profiles that will attach to binaries executed out of these directories. The trap profile can grant limited to no permissions. > There's no fine-grained enough Linux capability to fix this and > there's nothing in the AppArmor policy language to express "not > allowed to give files the setuid/setgid bits". I don't know if the > existing LSM hooks are sufficient for AppArmor to add such support > both in the kernel and in the policy language. But even if that > specific instance of the "groups of processes can cooperate to > escalate privileges" was fixed, the broader problem would remain. > AppArmor folks, can you confirm and maybe shed some light upon what > options we have here, both short and long term? > short term: confine users & a trap profile(s) on the /etc/cups dir long term: apparmor will pickup permissions to control setuid/setguid both at the file creation level and at the profile attachment level.
