Bug#1057787: [pkg-apparmor] Bug#1057787: apparmor scripts give SyntaxWarning messages with python3.12
Hello, Am Freitag, 8. Dezember 2023, 15:13:10 CET schrieb richardn: > python3.12 starts giving SyntaxWarning messages for invalid escape > sequences in the apparmor python scripts. With python3.11 these were > only DeprecationWarning messages, not shown by default. According to > release notes, in a future Python version SyntaxError will eventually > be raised, instead of SyntaxWarning > > These all seem to have been fixed upstream > > https://gitlab.com/apparmor/apparmor/-/commit/d94731ddf42f9a5f5db5ceb5 > 165d18547f010f63 I backported the fixes to the 3.1 branch, see https://gitlab.com/apparmor/apparmor/-/merge_requests/1130 AppArmor 3.1.7 (no release date planned yet) will include these fixes. Unfortunately backporting to the 3.0 branch results in lots of conflicts in a dozen of files, and I slightly ;-) doubt that supporting the latest Python in an older branch is worth the effort. Therefore I'd recommend that the Debian package gets upgraded to 3.1.x. Regards, Christian Boltz -- > Well I must admit I feel like an idiot, A typical feeling for each software developer ;) [> Dave Plater and Adrian Schröter in opensuse-buildservice] signature.asc Description: This is a digitally signed message part.
Bug#1057453: [pkg-apparmor] Bug#1057453: apparmor: typo in man apparmor_parser for --warn options
Hello, Am Dienstag, 5. Dezember 2023, 11:50:24 CET schrieb richardn: > man apparmor_parser gives examples for the --warn command line option > as > > apparmor_parser --warn=rules-not-enforced ... > and > apparmor_parser --warn=no-rules-not-enforced ... > > but the actual --warn options are rule-not-enforced / > no-rule-not-enforced (without s) Nice catch! This bug survived since 2014 (c2b8a72317), but I submitted the fix upstream before it wants to celebrate its 10th birthday ;-) https://gitlab.com/apparmor/apparmor/-/merge_requests/1128 Regards, Christian Boltz -- After a little bit of thinking* [...] * yes, I do it sometimes and yes, it usually hurts and leads to bad stuff, I'll try not to do it again [Jos Poortvliet in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#1054115: [pkg-apparmor] Bug#1054123: apparmor breaks nfs root
Hello, (cross-posting to the referenced bug so that the information appears in both bugs) Am Dienstag, 17. Oktober 2023, 14:18:43 CEST schrieb Anton Ivanov: > The default profile denies network functionality and it breaks > man and other software which has an apparmor profile. They stop > working on NFS. > > For an example see Debian bug 1054115 > > While it is possible to solve it on a case by case basis, the > right bugfix is to check if root and/or /usr are on NFS and > load an extra profile to allow network access. > > Alternatively, the kernel should stop treating network filesystem > access as network access for apparmor purposes. That, however, > is likely to a be a bit difficult. [...] > Kernel: Linux 5.10.0-22-amd64 (SMP w/12 CPU threads) This issue was fixed in kernel 6.0 [1] - which means your 5.10.0 kernel is too old and doesn't contain the fix yet. Unfortunately I don't know the exact commit, or how hard it would be to backport the fix to an older kernel. (If you are interested in backporting, I'd recommend to ask John Johansen for details.) If upgrading to a newer kernel is not an option, a possible workaround is to add network inet stream, network inet6 stream, to the affected profile or an abstraction - or to abstractions/base if you really want it in all profiles. Note: These two rules allow _all_ TCP/IP network access, not only NFS. Also note that abstractions/nameservice already contains these two rules (for DNS resolution etc.), so this workaround is already accidentally in place in some profiles ;-) Regards, Christian Boltz [1] see https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1784499 comment 13 -- Having presentation after lunch break when sun is shinning really sucks. [Josef Reidinger in yast-devel] signature.asc Description: This is a digitally signed message part.
Bug#1051503: [pkg-apparmor] Bug#1051503: Bug#1051503: AppArmor blocks Evolution launch
Hello, Am Samstag, 9. September 2023, 13:25:30 CEST schrieb intrigeri: > dp217 (2023-09-08): > > When trying to start the Evolution mail app, AppArmor does not allow > > it to start and displays a message: apparmor="DENIED" > > operation="mount" info="failed mntpnt match" error=-13 > > profile="/usr/bin/evolution" name="/" pid=1923 comm="bwrap" > > flags="rw, silent, rslave" > As far as I know we don't confine Evolution with AppArmor in Debian, > so I suppose you've installed or enabled a profile yourself, and then > I would encourage you to report this problem to the authors of > said profile. > > If my assumptions are incorrect, please help me understand :) comm="bwrap" looks like a hint towards bubblewrap, therefore my guess is that we are looking at a flatpak-packaged evolution here. But that's just a guess, so I'll wait for the feedback from the reporter. That said: The profile will need a mount rule added, probably mount options=(rw, silent, rslave) -> /, (I know allowing evolution or bwrap to mount / looks strange, even if it's inside a sandbox. But I'm afraid that's what the sandbox needs.) For the records. aa-logprof doesn't support mount rules yet (besides keeping/not breaking existing rules) which is why it doesn't ask anything for the DENIED event quoted above. Regards, Christian Boltz -- [Unterschied zwischen "echten" MB (1024 kB) und "Marketing-MB" (1000 kB] Wundert mich, daß Media Markt das noch nicht als Marktlücke entdeckt hat :-) 537 MB-Speichermodule als Ersatz für herkömmliche 512 MB Module für noch mehr Leistung - garantiert überall lauffähig, wo auch die normalen 512 MB Module laufen *vbeg*[Adalbert Michelic in suse-linux-faq] signature.asc Description: This is a digitally signed message part.
Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
Hello, Am Samstag, 2. September 2023, 01:13:11 CEST schrieb Mathias Gibbens: > A minimal reproducer is to install bookworm and create a container > with a systemd service using a hardening option like > PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the > service will fail. But, grab a kernel from testing (6.4.11-1) and then > things work -- with no other changes required. I tried the "oldest" > kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the > service works properly with that version as well. So, something > changed in the kernel (either upstream or in Debian's packaging) > between 6.1 and 6.3 that "unbreaks" services within lxc containers. I asked in #apparmor, and John answered [11:04:33] can someone have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050256 ? Short version: Debian gets unix denials when running lxc with kernel 6.1.38 from bookwork, but things work with kernel 6.3.1 [19:19:41] cboltz: ok, I will try and look at it today [07:00:34] cboltz: I didn't see anything that would cause unix failures in a first pass. I will take another pass at it tomorrow [10:01:30] cboltz: commit 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets So you could test if the bookwork kernel with 1cf26c3d2c4c applied on top fixes the issue. To answer a question from a later mail: Am Sonntag, 3. September 2023, 02:56:05 CEST schrieb Michael Biebl: > I also tested downgrading apparmor to 2.13.6-10 (i.e. the version from > oldstable) on a bookworm system. > > This was also sufficient to unbreak lxc. > > So it "looks" like apparmor 3.x makes assumptions about the kernel > that are not fulfilled by the kernel 6.1.x in bookworm. The difference is in the abi levels - without an abi/ include specified, unix rules don't get enforced (= allow everything), while with abi/3.0 and AppArmor >= 3.x userspace, unix rules get enforced. abi/3.0 got introduced in AppArmor 3.0, and my guess is that the abi/3.0 include was also added to the lxc profile. Actually the explanation might be slightly different (same result, but without abi/3.0 in the lxc profile): It looks like the Debian AppArmor maintainers pinned the abi to /etc/apparmor.d/abi/kernel-5.4-outoftree-network which, like abi/3.0, includes enforcing unix rules. (Note: I'm only looking at https://salsa.debian.org/apparmor-team/apparmor.git/ since I don't have a Debian machine running.) For completeness: 2.13.x doesn't support abi at all (besides ignoring abi/* includes if it finds them in a profile) so even if you have a profile with abi/3.0, unix rules won't be enforced. There's an exception: Ubuntu kernels carry some patches to enable unix and some other rules even with older AppArmor versions. Regards, Christian Boltz -- in my experience it's safe to assume developers never test [Stephan Kulow in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
Hello, Am Donnerstag, 31. August 2023, 08:41:59 CEST schrieb Michael Biebl: > What we found so far is, that the AppArmor policy of lxc breaks any > systemd service using PrivateNetwork=yes or PrivateIPC=yes when being > run under lxc (running under bookworm using the bookworm kernel). > I wonder what the best course of action is here. > Should we disable the AA policy of lxc via a stable upload of the lxc > package until the root cause is found? > > Unfortunately I know too little about AppArmor and lxc's AppArmor > policy and my attempts to ask around for help weren't successful so > far. Two quick hints, but let me warn you that I'm not familiar with lxc and also didn't check the content of the lxc-autopkgtest-lxc-iomhit_* profile. https://github.com/lxc/lxc/issues/4333 indicates that this issue was fixed in (much) a newer kernel - but that's probably not news to you since you wrote that comment ;-) That said - the DENIED log entry translates to unix send type=dgram, You could try if adding this rule to the lxc-autopkgtest-lxc-iomhit_* profile helps - but if the issue is really on the kernel side, my hope is limited). For testing, you could also try with a more broad unix send, or even unix, rule - but please don't add these broader rules to the production profile. Regards, Christian Boltz -- you need a certificate, nobody knows how to do that securely (including the CAs ;-) [Bernd Paysan, https://bugs.kde.org/show_bug.cgi?id=131083] signature.asc Description: This is a digitally signed message part.
Bug#932501: [pkg-apparmor] BTS housekeeping and severity adjustments
Hello, Am Freitag, 21. Juli 2023, 15:05:52 CEST schrieb Stefano Rivera: > > severity 932501 serious > > I'm wondering if this bug should really be serious. Squid's apparmor > config is shipped disabled, so one has to manually enable it to > trigger this bug. > > I would have gone for normal/important. > > I don't know what the correct solution to this bug is. Presumably one > has to get the squid profile to include the abstraction that > squid-deb-proxy provides. I don't know how this is usually done in a > Debian package. Maybe one of the apparmor team can comment. The interesting part is that the abstraction is shipped in squid-deb- proxy, while the squid profile comes from another package (I didn't check which one). I guess the best you can have is to add include if exists in the squid profile so that it will include the abstraction if it exists, and doesn't complain if it doesn't. Note that the AppArmor profile cache is only timestamp-based [1], so if you install squid-deb-proxy (and had the squid AppArmor profile loaded before), it might happen that the cache file is never than the squid-deb- proxy abstraction, with the result that the cache doesn't get updated. (Workaround: delete the cache file, then reload the profile.) The alternative is to add the rules needed for squid-deb-proxy directly to the squid profile. This adds some "superfluous" rules for people who don't use squid-deb-proxy, but on the positive side it avoids the cache issue. BTW: https://packages.debian.org/sid/all/squid-deb-proxy/filelist says the abstraction is packaged as /etc/apparmor.d/abstractions/squid-deb-proxy/squid-deb-proxy which looks slightly wrong ;-) It should just be /etc/apparmor.d/abstractions/squid-deb-proxy (assuming no other files get deployed to /etc/apparmor.d/abstractions/squid-deb-proxy/ ) Bonus points if you add include if exists to the abstraction ;-) For the records: include if exists needs AppArmor >= 3.0 userspace. Regards, Christian Boltz [1] Using a better cache validation method like checking the checksum of the text profile is on the TODO list upstream, but not implemented yet. -- [SuSE vs. SUSE] As a friend of mine elsewhere remarked, the picky spelling capitalization scheme reinforces the idea that Linux is case-sensitive, so these are "sensitive" issues and certainly worth discussing (for us, at least)! :) [Shriramana Sharma in opensuse] signature.asc Description: This is a digitally signed message part.
Bug#1030153: [pkg-apparmor] Bug#1030153: complaining
Hello,
Am Mittwoch, 1. Februar 2023, 16:00:06 CET schrieb Antoine Beaupré:
> On 2023-01-31 23:57:04, Christian Boltz wrote:
> > I'm somewhat surprised about that because the upstream profile for
> > sshd has the following rule since Dec 3 2016 :
> > /{usr/,}bin/bash Uxr,
[...]
> > Now I wonder - does your sshd profile lack this line/rule?
> > (If in doubt, please attach the complete profile.)
[...]
> I *think* those are some "extra" profiles I might have manually
> deployed at some point.
Possibly. That must have been years ago ;-)
> Now that I dig in the apparmor-profiles, I found a
> /usr/share/apparmor/extra-profiles/ directory and there *is* a
> usr.sbin.sshd profile in there. So I'm not sure what happened here,
> maybe I deployed those by hand but they never got updated?
Sounds like a valid explanation. The extra profiles never get copied to
/etc/apparmor.d/ automatically *), which also means they don't get
updated automatically.
*) only exception: aa-genprof offers to use them as starting point when
creating a _new_ profile
> I also am a little confused by apparmor-profiles shipping an
> "extra-profiles" directory *and* having at the same time an
> apparmor-profiles-extra that only ships a handful of profiles... It's
> all very confusing...
That's something one of the Debian packagers needs to answer.
(I use another distribution, see my signature ;-)
> Here's that old profile that was causing problems:
[...]
> /usr/sbin/sshd flags=(complain) {
[...]
> /bin/bash rUx,
That explains it - it doesn't allow /usr/bin/bash to be executed.
I'd recommend to copy over the latest sshd profile from extra-profiles to
/etc/apparmor.d/.
Regards,
Christian Boltz
--
> Using the internet since 28.8kbit. Yes, I'm 'old'.
My first modem was 300 bits/sec, you young whipper snapper! ;-)
[> Yamaban and James Knott in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#1030153: [pkg-apparmor] Bug#1030153: complaining
Hello,
Am Dienstag, 31. Januar 2023, 19:20:38 CET schrieb Antoine Beaupré:
> so something is happening with apparmor here. it looks like profile
> are "piling up" in some way, with something like this:
>
> /usr/sbin/sshd//null-/usr/bin/bash//null-/usr/bin/sudo//null-/usr/bin/
> apt//null-/usr/bin/dash//null-/usr/bin/etckeeper//null-/etc/etckeeper/
> pre-install.d/50uncommitted-changes//null-/usr/bin/etckeeper//null-/us
> r/bin/perl
That means sshd executed /usr/bin/bash (without having an execute rule),
and bash executed /usr/bin/sudo, which executed /usr/bin/apt, and so on.
I'm somewhat surprised about that because the upstream profile for sshd
has the following rule since Dec 3 2016 :
/{usr/,}bin/bash Uxr,
This rule should allow to execute /bin/bash and /usr/bin/bash in
unconfined mode (= without AppArmor restrictions) - and therefore should
also avoid the long chain you see.
However, your log looks like your profile does not allow executing
/usr/bin/bash.
Now I wonder - does your sshd profile lack this line/rule?
(If in doubt, please attach the complete profile.)
Regards,
Christian Boltz
--
But you are probably also complaining if local root exploits in the
kernel are fixed, because now you no longer can use that to become root
easily... [Stefan Seyfried in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#1024707: [pkg-apparmor] Bug#1024707: aa-disable fails if HOMEDIRS is used as tunable
Hello,
Am Mittwoch, 23. November 2022, 15:58:30 CET schrieb Erik Thiele:
> Package: apparmor-utils
> Version: 2.13.2-10
> # cat /etc/apparmor.d/tunables/home.d/yyy
> @{HOMEDIRS}+=/home/global/
> # aa-disable usr.bin.thunderbird
> ERROR: Values added to a non-existing variable
> @{HOMEDIRS}: /home/global/ in tunables/home.d/yyy
> this may be linked to
> https://bugs.launchpad.net/apparmor/+bug/1331856
Indeed, and the relevant part is comment 16:
This bug is finally fixed with
https://gitlab.com/apparmor/apparmor/-/merge_requests/544
AppArmor 3.0 will include the fixed tools.
Unfortunately you / your Debian version still have 2.13.x, and the merge
request is too big to backport it to the 2.13 branch.
As long as you stay with AppArmor 2.13.x and want to use the aa-* tools,
the workaround is to edit /etc/apparmor.d/tunables/home instead of
using a home.d/ file to extend a variable with +=
Regards,
Christian Boltz
--
> I like science when some "vodoo" is needed to make it work ;-)
Magic is just another word for indistinguishable advanced technology :D
[> Bruno Friedmann and Jan Engelhardt in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#980974: apparmor blocks cups backend outgoing network connections
Hello, denials for capabilty net_admin are often a sign that a service uses systemd libraries on startup, and these systemd libraries do funny[tm] things. In these cases the net_admin capability is not really needed. See https://bugzilla.opensuse.org/show_bug.cgi?id=1196850#c3 for the technical details. (Yes, I'm aware that this bugreport is for Samba, not cups - but I'm somewhat sure that cups uses the same systemd libraries on startup.) I have to admit that I'm only a cups user, but I'd be surprised if it really needs capability net_admin. To find out if it's really needed or just "systemd noise", can you please explicitely deny net_admin and test if printing still works? To do this, add deny capability net_admin, to /etc/apparmor.d/local/usr.sbin.cupsd This will a) deny it and b) silence the logging. Then reload the profile with systemctl reload apparmor I'd also recommend to aa-enforce cupsd (in theory deny rules get enforced even in complain mode, but better safe than sorry) If printing doesn't work with the deny rule added, please try if it works if you allow the capability: capability net_admin, (and remove the deny rule). Note, since this bug includes two different AppArmor denials: capability sys_nice, for cups-browsed is unrelated to what I wrote above. Please don't change your cups-browsed profile (= keep it in complain mode) while testing the deny rule in the cupsd profile. Regards, Christian Boltz -- > check up on dusted up coolers / vents etc. That is the first thing that I did, but I can't imagine that the amount of dust is automatically changing with the kernel ? [> David Haller and Raymond Wooninck in opensuse-factory]
Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables
Hello,
Am Mittwoch, 5. Januar 2022, 23:09:01 CET schrieb Karsten Hilbert:
> Unless I misunderstand apparmor profile logic it is not
> purely cosmetic. It excludes "/home/*/" from @{HOME}.
That's the difference between a human parser (you) and apparmor_parser
;-) - you think of the profile as "code" (where order matters) while
apparmor_parser (mostly) doesn't care about the order.
I'll try to explain how apparmor_parser works using pseudo-SQL:
Step 1: read tunables/home
@{HOME}=@{HOMEDIRS}/*/ /root/
-> INSERT INTO variables VALUES ( '@{HOME}', '@{HOMEDIRS}/*/ /root/');
@{HOMEDIRS}=/home/
-> INSERT INTO variables VALUES ( '@{HOMEDIRS}', '/home/');
Now we have the two variables in the variables database.
Note that @{HOME} was stored "raw", without expanding the embedded
variable. Therefore the order of the variable declaration (or INSERT
commands) doesn't matter.
Step 2: if a rule uses one of the variables:
@{HOME}/foo r,
apparmor_parser: "that rule contains a variable! Let's look it up..."
-> SELECT FROM variables WHERE name='@{HOME}';
Result: @{HOMEDIRS}/*/ /root/
apparmor_parser: "oh, that contains another variable, let's look it up
too..."
-> SELECT FROM variables WHERE name='@{HOMEDIRS}';
Result: /home/
apparmor_parser: "and now let me replace that variable in @{HOME}..."
Original: @{HOMEDIRS}/*/ /root/# replace @{HOMEDIRS} with /home/
Result: /home/*/ /root/
apparmor_parser: "Looks good. That variable has two items, split it and
update the rule..." (which gives us two rules, one for each variable
item)
Result: /home/*/foo r, /root/foo r,
Does that help to understand what's going on?
Regards,
Christian Boltz
PS: The above is simplified (for example, it doesn't have "SQL" for
extending variables with "+="). Also, apparmor_parser doesn't use
SQL or a database internally - but the actual data structure/storage
is just a technical detail you can ignore for now.
Also, inserting the variables into the rule will give you
alternations (not multiple rules), but that's also just a technical
detail.
One detail I didn't mention is that the replacement in step 2 is
that slashes get de-duplicated so that you end up with /home/*/
instead of /home//*/ which you would get by blindly replacing the
variable.
--
darix: I need to go, let's continue tomorrow if you have
time
tomorrow i will be drunk or so
darix: count on me for that state :-)
[from #opensuse-admin]
signature.asc
Description: This is a digitally signed message part.
Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables
Hello,
AppArmor rules are in most cases declarative so that the order doesn't
matter (exception: before you can extend a variable with "+=" you have
to initialize it with "=").
The current definition is technically not a bug, "just" confusing.
However, I agree that defining @{HOMEDIRS} before using it would make
sense to make it less confusing for human parsers ;-)
I submitted a patch for re-ordering the variable definition upstream:
https://gitlab.com/apparmor/apparmor/-/merge_requests/820
Since the change is more cosmetic, it will probably only be included in
AppArmor 3.1 and newer. I don't expect to get it backported to the 3.0
or 2.x branches.
Regards,
Christian Boltz
--
> Using the internet since 28.8kbit. Yes, I'm 'old'.
My first modem was 300 bits/sec, you young whipper snapper! ;-)
[> Yamaban and James Knott in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#1003153: [pkg-apparmor] Bug#1003153: /etc/apparmor.d/usr.sbin.apache2: Apache profile complains when ss -tnlp is run
Hello, Am Mittwoch, 5. Januar 2022, 03:31:40 CET schrieb Craig Small: > audit: type=1400 audit(1641349042.460:2559): apparmor="DENIED" > operation="ptrace" profile="apache2//HANDLING_UNTRUSTED_INPUT" > pid=2792993 comm="ss" requested_mask="readby" denied_mask="readby" > peer="/bin/ss" > > So ss is doing a ptrace on all the network listeners. The odd thing is > that apache is the only one to complain about this even though other > daemons listed have their own apparmor profiles. That's not really odd ;-) abstractions/base has ptrace (readby), ptrace (tracedby), so all profiles that include abstractions/base can be ptraced. However, what you see happens in the HANDLING_UNTRUSTED_INPUT hat (this hat is used when Apache processes are idle) - and Apache hats typically don't include abstractions/base. (Nevertheless, the apache hats should allow to be ptraced. I'll leave that to the maintainer of the Apache profile in Debian - and would love to see the fix upstreamed.) Regards, Christian Boltz -- okay. when can we have the next power outage, for testing purposes ? [from #opensuse-admin] signature.asc Description: This is a digitally signed message part.
Bug#1002560: [pkg-apparmor] Bug#1002560: /usr/sbin/aa-logprof: aa-logprof doesn't understand include if exists
Hello, Am Freitag, 24. Dezember 2021, 03:41:57 CET schrieb Craig Small: > Package: apparmor-utils > Version: 2.13.6-10 > aa-logprof doesn't understand any lines that have include if exists. Support for "include if exists" was added to aa-logprof in version 3.0. Unfortunately the patch is quite big, which makes backporting to the 2.13 branch nearly impossible. I'm afraid you'll either need to upgrade to 3.x - or avoid using "include if exists" as long as you use 2.13.x. Regards, Christian Boltz -- > We could call it openSUSE 11.11.11 ;-) I'd prefer we use the US date format: 11.11.11 ;-) [> Freek de Kruijf and Greg Freemyer in opensuse-project] signature.asc Description: This is a digitally signed message part.
Bug#988204: [pkg-apparmor] Bug#988204: Improved patch
Hello, Am Montag, 8. November 2021, 20:53:01 CET schrieb Alistair J R Young: > An improved patch for this issue follows, in accordance with the above > thread: > > --- rc.apparmor.functions 2021-11-08 13:27:06.461249682 -0600 > +++ rc.apparmor.functions 2021-11-08 13:30:05.766141212 -0600 Your patch looks like something that should (also?) be fixed upstream. May I ask you to submit a MR at https://gitlab.com/apparmor/apparmor/ ? (If you don't want to do the upstreaming for whatever reason, I can forward your patch - but usually it's better to avoid a "relay" ;-) Regards, Christian Boltz -- Hmmm I think I hear steve yelling something about a unit test, but he is on vacation so I'll just ignore him for now ;) [John Johansen in apparmor] signature.asc Description: This is a digitally signed message part.
Bug#993568: [pkg-apparmor] Bug#993568: dh-apparmor: Allow opting-out from creating local include
Hello, Am Freitag, 3. September 2021, 10:01:47 CEST schrieb intrig...@debian.org: > "include if exists" is well supported in AppArmor 3.x, > so we could stop creating /etc/apparmor.d/local/$profile > local include files. > > I don't think we can do that by default though: if we did, it would > break loading newly installed profiles that still use #include. Interestingly I received a similar proposal for openSUSE and will probably stop shipping the local/* sniplets with the 3.1 release. (Handling / cleaning up existing local/* files without getting modified files moved away is an interesting[tm] packaging exercise. I'm not sure how much the handling of that can be shared betwen RPM and DEB packages, but we should at least try to avoid duplicate work.) This also leads to the questiion if upstream AppArmor should by default stop generating the local/* sniplets in profiles/Makefile. Since all profiles shipped with the upstream tarball use "include if exists", that wouldn't break anything. Anyway - back to the original topic ;-) I see two possible options: - add an option to dh_apparmor to not create the local/ sniplet (disadvantage: needs adjustments in all packages that don't want the local/ file; advantage: no "surprising" behaviour change) - make dh_apparmor a bit more intelligent and grep the profile for the local include. If it finds "include " it should create the local/ file, but if it finds "include if exists " it could stop creating that file. Or, to make it more error-proof, create the local/ file if it doesn't find "include if exists ". [Note: I don't know the current dh_apparmor code.] (advantage: no need to adjust any package; disadvantage: applying grep magic to the real world is sometimes not as easy as it looks) BTW: If you want to use grep, you can steal the grep regex from the upstream profiles/Makefile (in the "local:" target). Regards, Christian Boltz -- A bug a day keeps the doctor away - ke 2006 [bugzilla.novell.com quips] signature.asc Description: This is a digitally signed message part.
Bug#991076: python3-coverage should have libjs-jquery* in Depends instead of Recommends
Hello, Am Mittwoch, 14. Juli 2021, 01:04:16 CEST schrieb Ben Finney: > Control: retitle -1 python3-coverage should have libjs-jquery* in > Depends instead of Recommends > On 13-Jul-2021, Christian Boltz wrote: > > Package: python3-coverage > > (Assuming this is the package that should be mentioned in the title of > this bug report, I've retitled to match.) Thanks, and sorry for the typo in the subject. > > After some searching, I found out that I need to install some > > additional packages: > > libjs-jquery libjs-jquery-throttle-debounce > > libjs-jquery-isonscreen libjs-jquery-tablesorter > Right. Those are in Recommends, so will be installed by default. > > > They are already listed under "Recommends:", but since the coverage > > module is not very useful if it can't generate html reports, please > > list them under "Depends:" instead of "Recommends:". > > People who choose to disable the default installation of Recommends > packages, are assumed to want a package to declare in Depends only the > minimum packages that will make this package work. Agreed on the minimum package set, but we probably have different definitions of "make this package work" ;-) > The Python coverage system can be used for its main purpose without > ever generating any HTML reports; I think that satisfies Recommends > instead of Depends for the HTML support. Personally, my main usage are HTML reports (with the goal to have 100% test coverage), so usecases obviously differ, and I'd really like to have a Depends: for the libjs-jquery* packages. I even have a check in the CI to ensure that files that reached 100% coverage stay there (and let the CI fail if they are no longer 100% covered). Now I hit a case where coverage in one file randomly (and so far not reproducible) shows one "partial" line - and that was the reason to let the CI generate HTML reports so that I can find out the reason. Well, I first had to find out why the jquery files were missing and how to get them. Maybe we can meet somewhere in the middle ;-) Would it be possible to patch the error message so that it gives a hint about the missing packages? For example the error message could say: Couldn't find static file 'jquery.min.js' from '/builds/cboltz/apparmor/utils/test', tried: ['/usr/share/javascript/jquery.min.js', '/usr/share/javascript/jquery/jquery.min.js', '/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery.min.js', '/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery/jquery.min.js'] Please make sure the following packages are installed: libjs-jquery libjs-jquery-throttle-debounce libjs-jquery-isonscreen libjs-jquery-tablesorter (This would, like the patch that prevents packaging htmlfiles/*.* in python3-coverage, be a Debian-only patch that can't go upstream.) Regards, Christian Boltz -- Sorry for my usless answer should have drank my coffee and read the thread properly [Simon Lees in opensuse-packaging]
Bug#991076: python3-coverity should have libjs-jquery* in Depends instead of Recommends
Package: python3-coverage Version: 5.1+dfsg.1-2+b2 Severity: normal Hello, I tried to generate a HTML coverage report in a CI script that does apt-get install --no-install-recommends -y python3-coverage [...] However, it failed with # /usr/bin/python3 -m coverage html --omit="test-*.py,common_test.py" Couldn't find static file 'jquery.min.js' from '/builds/cboltz/apparmor/utils/test', tried: ['/usr/share/javascript/jquery.min.js', '/usr/share/javascript/jquery/jquery.min.js', '/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery.min.js', '/usr/lib/python3/dist-packages/coverage/htmlfiles/jquery/jquery.min.js'] After some searching, I found out that I need to install some additional packages: libjs-jquery libjs-jquery-throttle-debounce libjs-jquery-isonscreen libjs-jquery-tablesorter They are already listed under "Recommends:", but since the coverage module is not very useful if it can't generate html reports, please list them under "Depends:" instead of "Recommends:". Regards, Christian Boltz -- As long as there are Steam games where updates are at least as big as the openSUSE first-time installation, I feel no regrets :-) [Jan Engelhardt in opensuse-factory]
Bug#984582: [pkg-apparmor] Bug#984582: apparmor FTCBFS: many different reasons
Hello, Am Freitag, 5. März 2021, 13:07:45 CET schrieb Helmut Grohne: > 4. Then it uses AC_CHECK_FILE to locate a header. Bad idea. >AC_CHECK_FILE is for host files, not for build files. Please use > test -e instead. > 6. The configure script assumes that $PYTHON-config is right. >Unfortunately, the Python interpreter is not usually prefixed with > a triplet whereas the -config tool is. Thus we get the build > architecture python-config here, but we should use the host one. > AC_PATH_TOOL is required here. These two fixes (both in the added cross.patch) affect upstream code, and I'd guess that they are not Debian-specific. Would you be willing to submit these fixes upstream at https://gitlab.com/apparmor/apparmor/-/merge_requests ? I can't really comment on the debian/* changes - EWRONGDISTRO ;-) Regards, Christian Boltz -- I guess it's time to extend Zawinski's Law with: Every (mail-reading) program will expand until it can no longer read mail. [Jan Engelhardt in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#712451: [pkg-apparmor] Bug#712451: Special case
Hello, Am Donnerstag, 7. Januar 2021, 13:22:42 CET schrieb Christian Ehrhardt: > A special case worth mentioning in this case might be that while > normal profiles get re-loaded after being installed - this is not > required (nor working) for abstraction files. I'm not sure if this comment was really meant for this bug, but I'll answer nevertheless ;-) (If it was on the wrong bug, feel free to also forward the comment below to the right one.) You are right that you can't reload an abstraction. However, you could reload all profiles ;-) and maybe you should consider to do this if an abstraction changes. (In theory it could have side effects if there are modified, but intentionally-not-yet-reloaded profiles. In practise, I'd prefer these side effects over having profiles with outdated abstractions loaded.) Regards, Christian Boltz PS: In case you wonder - the openSUSE package apparmor-abstractions reloads all profiles in its postinstall script. -- Yes my friends, 0 is the unlucky number of software, with 6 as a secondary. (Think IE 6, Perl 6, PHP 6, ...) [Jan Engelhardt in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Hello, I'd argue that this is a problem that is already solved ;-) Starting with AppArmor 3.0, all[1] upstream abstractions come with a rule like (example taken from abstractions/base): include if exists so if you create that directory and place a file there, it will be included by the abstraction. You don't need to provide those directories or dummy files via the package, and in fact I'd say that they should only be created when really needed to keep /etc/apparmor.d/ readable. (Obviously, if a program needs to extend a specific abstraction, packaging an abstractions/$abstraction.d/$package file makes sense.) For abstractions shipped by individual package (like libvirt), it would also make sense to add an include if exists rule to make it easy to add something to an abstraction. Note: up to AppArmor 2.13.x, the aa-* tools (aa-logprof etc.) break in funny ways when hitting include if exists rules, and sadly that's not easy to fix (ETOOBIGPATCH). Therefore I'd recommend not to backport include if exists rules to profiles or abstractions in older distros. The aa-* tools from AppArmor 3.x fully support include if exists rules. Regards, Christian Boltz [1] The only exception is abstractions/ubuntu-browsers because (for historic reasons) an abstractions/ubuntu-browsers.d directory already exists and is used in a different way. -- seccheck runs here on a host that contains 3 daily backups of 10+ SAP hosts, and the "Local Monthly Security" Mail size is 562 MB. This mail size causes an unfriednly, suspicious grin on the face of my mail admin... [Werner Flamme in opensuse-security] signature.asc Description: This is a digitally signed message part.
Bug#973356: [pkg-apparmor] Bug#973356: apparmor-profiles: complain on syslog-ng opening system.journal until re-enabling profile
Hello,
Am Donnerstag, 29. Oktober 2020, 12:43:08 CET schrieb Lorenzo Iannuzzi:
> apparmor="ALLOWED" operation="open" profile="syslog-
> ng//null-/bin/dash//null-/usr/sbin/sshguard//null-/bin/journalctl"
This is interesting[tm] - syslog-ng executed dash, which then executed
sshguard, which executed journalctl.
That looks like a funny way to read from the journal...
> name="/run/log/journal/ccca544565cf1834599ef913deceef00/system.journal
> " pid=6749 comm="journalctl" requested_mask="r" denied_mask="r"
> fsuid=0 ouid=0
>
> I can see some rules from profile that should permit the access to
> that file:
> /{var,var/run,run}/log/journal/ r,
> /{var,var/run,run}/log/journal/*/ r,
> /{var,var/run,run}/log/journal/*/*.journal r,
Right, but there are no rules that allow to execute dash, sshguard and
journalctl.
> and if I disable and enable again the profile (with aa-disable and
> aa-complain) log messages doesn't show anymore.
aa-disable unloads the profile from the kernel, which also means that
running processes become unconfined.
aa-complain loads the profile again (in complain mode), but it can't
apply it to running processes, so they stay unconfined (until you
restart them).
Note that this probably only affects the syslog-ng profile, not the
processes running under the syslog-ng//null-* profiles.
The better way is to use only aa-complain, which will switch the profile
to complain mode and leave running processes confined.
> Why those log are shown on boot, but disappear after I reload the
> syslog-ng profile?
See above, it's probably because you first unload the profile with aa-
disable and then have syslog-ng running unconfined.
Can you please check if there are processes running under a profile
starting with "syslog-ng"? You can do this with
ps Zaux | grep ^syslog-ng
Ideally check it before and after reloading the profiles.
Also restart syslog-ng and check again.
Also, do fresh log messages appear if you restart syslog-ng?
Bonus question: Do you have a non-default syslog-ng config that could
explain the exec chain I mentioned at the beginning?
Regards,
Christian Boltz
--
> Would it be ok to just switch all build sections to use lua?
> Probably much faster than the shells anyway :-P
Yast team has experience in converting strange languages to
each other - they can cook something! :)
[> Stefan Seyfried and Stephan Kulow in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#972634: [pkg-apparmor] Bug#972634: apparmor- profile can not define message queue name or directory
Hello,
Am Mittwoch, 21. Oktober 2020, 16:46:12 CEST schrieb Bossler Daniela:
> We want to open a posix message queue in a user defined function under
> mysqld. Mysqld has a apparmor-profile without any queue access rigths
> (/dev/mqueue). We added /dev/mqueue/** rw to the profile but mysqld
> can not open any queue with mq_open(). Next we tried to add the queue
> name to the profil (/sp-example-server w,), but the problem/bug? is
> that the profile entries must begin with a "/" and the queue names
> are passed by mq_open to apparmor without the slash. So it's not
> possible to allow access to the posix-queue.
>
> Is there a workaround?
My crystal ball says that you get a log entry like this:
(irrelevant and unguessable ;-) parts replaced with "...")
type=AVC msg=audit(...): apparmor="DENIED" operation="..."
info="Failed name lookup - disconnected path" error=-13 profile="..."
name="sp-example-server" pid=... comm="..." requested_mask="w"
denied_mask="w" fsuid=... ouid=...
If my guess is right and the message really reports "disconnected path",
then you'll need to add the attach_disconnected flag to the profile,
something like:
profile mysql /usr/bin/mysqld flags=(attach_disconnected {
If my guess was wrong, please provide the audit.log messages you see -
they would help to clean the nebulous areas on my crystal ball ;-)
Regards,
Christian Boltz
PS: non-random signature ;-)
--
you could be correct in that bugzilla may not be useful in predicting
either when the bug will be resolved, or the weather next month.
so, maybe subscribe to [opensuse-crystal_ball] is the best bet.
[DenverD in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#959915: [pkg-apparmor] Bug#959915: redundant freshclam profile since it's shipped in-package
Hello,
Am Montag, 25. Mai 2020, 11:22:01 CEST schrieb intrigeri:
> FTR, here's the profile shipped in the clamav-freshclam package:
> https://salsa.debian.org/clamav-team/clamav/-/blob/unstable/debian/usr
> .bin.freshclam It has been updated a few times in the last few years.
>
> And here's the upstream one from the AppArmor project:
> https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/apparmor/p
> rofiles/extras/usr.bin.freshclam It has been updated once in the last
> 10 years.
... and it works on my openSUSE servers (and nobody reported issues from
other distros), which means there was no reason for additional updates
;-)
> I would love to see cross-distro collaboration on this profile, but
> our current infrastructure & processes are not ready for that yet,
> and I lack time/energy to push this forward myself.
I compared both profiles, and to cover both Debian and openSUSE, you'd
need to add the following lines to the Debian profile:
#include# rule exists since the original
# profile version in 2006, no idea if it's really needed
# openSUSE configfile paths
/etc/clamd.conf r,
/etc/freshclam.conf r,
I'd recommend to change the pidfile rule to have the owner restriction
if possible:
#/{,var/}run/clamav/freshclam.pid w, # from Debian profile
owner /{,var/}run/clamav/freshclam.pid w, # upstream profiles/extra
I also wonder about ~/.clamtk/db/ and ~/.klamav/database/ (which I
obviously don't need for server usage) - but I'm sure Jamie had good
reasons to allow that ;-)
If you open a merge request upstream, I'll happily review it ;-)
Feel free to commit the Debian profile + the additional rules listed
above - that's probably easier than integrating the profiles the other
way round.
Regards,
Christian Boltz
--
>> emoenke@ftp4:4 /mirr/bin > du -s /pub/opensuse/distribution/*
> Using `du -sh` might be more readable. ;-)
Not for me - only for so called "humans".
[> houghi and Eberhard Moenkeberg in opensuse]
signature.asc
Description: This is a digitally signed message part.
Bug#956175: [pkg-apparmor] Bug#956175: Bug#956175: while removing apparmor, virgin /etc/apparmor.d/local/usr.bin.man missed
Hello, Am Samstag, 25. April 2020, 08:44:51 CEST schrieb intrigeri: >A possible mitigation would be that man-db starts creating+owning >the /etc/apparmor.d/local directory as well. Every other package >that uses dh_apparmor should do the same, then. If this could be >automated, fine. Else, IMO that approach requires too much busywork > to be worth it, given the problem we're talking about causes no > practical harm. There might be another option: Change include to include if exists and no longer create the local/foo file by default. I just added this idea to the agenda for the next upstream meeting (next Tuesday), let's see what the others think about it. Regards, Christian Boltz -- I blame containers. But then I blame containers for most things. [Liam Proven in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#956175: [pkg-apparmor] Bug#956175: while removing apparmor, virgin /etc/apparmor.d/local/usr.bin.man missed
Hello, Am Mittwoch, 8. April 2020, 04:16:03 CEST schrieb 積丹尼 Dan Jacobson: > Purging configuration files for apparmor (2.13.4-1) ... > dpkg: warning: while removing apparmor, directory > '/etc/apparmor.d/local' not empty so not removed $ find > /etc/apparmor.d/local > /etc/apparmor.d/local > /etc/apparmor.d/local/usr.bin.man > $ cat /etc/apparmor.d/local/usr.bin.man > # Site-specific additions and overrides for usr.bin.man. > # For more details, please see /etc/apparmor.d/local/README. I don't use Debian ;-) but I have a wild guess / question: Is the usr.bin.man profile part of the apparmor package, or is is managed in the man package? If I can trust $searchengine, the command to check [1] is probably dpkg -S /etc/apparmor.d/usr.bin.man dpkg -S /etc/apparmor.d/local/usr.bin.man If the file is owned by the man package, the man package might need to co-own the directory, or needs a dependency on the apparmor package to ensure the directory exists. Regards, Christian Boltz [1] I'm used to rpm -qf $file - but that won't work on Debian ;-) -- 0830?? on day 2 at FOSDEM? Good lord it will be a small miracle if I'm out of bed at that time, never mind at the venue ;) [Richard Brown in opensuse-project] signature.asc Description: This is a digitally signed message part.
Bug#949450: [pkg-apparmor] Bug#949450: thunderbird: tb not usable with apparmor profile enabled.
Hello,
I'm not the maintainer of the thunderbird profile nor using Debian, but
maybe I can give some helpful input nevertheless ;-)
(Updating the shipped profile has to be done by someone else.)
Am Freitag, 31. Januar 2020, 11:46:49 CET schrieb Dimitris:
> On 1/30/20 2:11 PM, Dimitris wrote:
...
> > [Thu Jan 30 2020] audit: type=1400 audit(1580374356.923:36):
> > apparmor="DENIED" operation="open"
> > profile="thunderbird//sanitized_helper"
> > name="/tmp/clearsigned.message.pycT1r" pid=23600 comm="apt-cache"
> > requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
That looks interesting[tm] - why would apt-cache want to access a
tempfile that looks like (wild guess based on the filename) a signed
message?
[...]
> > audit: type=1400 audit(1580377190.735:2836): apparmor="DENIED"
> > operation="file_inherit" profile="thunderbird//gpg"
> > name=2F6
> > D6C pid=13850 comm="gpg" requested_mask="a"
> > denied_mask="a" fsuid=1000 ouid=1000
> >
> > (replaced chars in between with Xs, since i don't know what this
> > could be..?)
That's a hex-encoded filename - this encoding gets used in the log if a
filename contains for example a space or special characters.
You can decode it with
aa-decode 2F6D6C
(obviously use the original name, not the X'ed out one)
>From the X'ed out name, I can say that it starts with, surprise, "/"
(2F) and ends with "l" (6C)
> new messages emerging making tb/enigmail unusable :
>
> audit: type=1400 audit(1580465922.867:14): apparmor="DENIED"
> operation="capable" profile="thunderbird" pid=11974 comm="thunderbird"
> capability=21 capname="sys_admin"
That's interesting[tm]. Wild guess: maybe thunderbird uses some
sandboxing that needs this capability to initialize?
> audit: type=1400 audit(1580465924.499:15): apparmor="DENIED"
> operation="open" profile="thunderbird" name="/etc/mate/defaults.list"
> pid=11974 comm="thunderbird" requested_mask="r" denied_mask="r"
> fsuid=1000 ouid=0
That translates to /etc/mate/defaults.list r, for the thunderbird
profile - or an abstraction. (We don't have a mate abstraction yet,
maybe it's time to start one? ;-)
> audit: type=1400 audit(1580465929.463:16): apparmor="DENIED"
> operation="file_lock" profile="thunderbird"
> name="/home/user/.cache/thunderbird/profile.default/OfflineCache/index
> .sqlite" pid=11974 comm="thunderbird" requested_mask="k"
> denied_mask="k" fsuid=1000 ouid=1000
k is for "file lock". The strictest-possible rule would be
/home/*/.cache/thunderbird/profile.default/OfflineCache/index k,
> audit: type=1400 audit(1580465955.367:18): apparmor="DENIED"
> operation="file_inherit" profile="thunderbird//gpg"
> name="/home/user/.icedove/profile.default/ImapMail/account1/INBOX.sbd/
> folder" pid=13491 comm="gpg" requested_mask="w" denied_mask="w"
> fsuid=1000 ouid=1000
>
> audit: type=1400 audit(158045.275:19): apparmor="DENIED"
> operation="file_inherit" profile="thunderbird//gpg"
> name="/home/user/.icedove/profile.default/prefs-1.js" pid=20428
> comm="gpg" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
These two look like a case of thunderbird not closing files when
executing gpg. You can probably ignore or deny that.
> audit: type=1400 audit(158045.279:20): apparmor="DENIED"
> operation="exec" profile="thunderbird//gpg" name="/usr/bin/gpg-agent"
> pid=20430 comm="gpg" requested_mask="x" denied_mask="x" fsuid=1000
> ouid=0
Ah, gpg wants to execute gpg-agent. That makes sense.
The easiest solution would be to add
/usr/bin/gpg-agent mrix,
to the gpg subprofile.
A more strict version would be
/usr/bin/gpg-agent mrPx -> thunderbird//gpg-agent,
to the gpg subprofile, and then to create a child profile called
gpg-agent:
profile gpg-agent {
# TODO
}
As a sidenote - soneone in the #apparmor IRC channel (on OFTC) spent
some work on creating a profile for thunderbird a few weeks ago.
Unfortunately the pastebin links have expired, but if you are
interested, I can try to get it uploaded somewhere again.
BTW: While you work on the profile, you might want to put it into
complain mode. Without knowing the exact profile filename:
aa-complain /etc/apparmor.d/*thun
Bug#944003: [pkg-apparmor] Bug#944003: apparmor: Fails to build for python 3.8
Hello, Am Samstag, 2. November 2019, 16:20:10 CET schrieb intrig...@debian.org: > As discovered on #942663, src:apparmor fails to build for python 3.8. ... > - upstream Git: libraries/libapparmor/m4/ac_python_devel.m4 > > - upstream tarball: libraries/libapparmor/configure This is part of the libapparmor bindings which are generated with swig, which I'm not really familiar with. However, there's an interesting detail on http://www.swig.org/Release/RELEASENOTES for swig 4.0.1 (which is the latest release): - Add Python 3.8 support. Which swig version gets used in the failing builds? If it's older than 4.0.1, then updating swig is probably the first thing to do/test ;-) Note that this is just a wild guess ;-) Regards, Christian Boltz -- seccheck runs here on a host that contains 3 daily backups of 10+ SAP hosts, and the "Local Monthly Security" Mail size is 562 MB. This mail size causes an unfriednly, suspicious grin on the face of my mail admin... [Werner Flamme in opensuse-security] signature.asc Description: This is a digitally signed message part.
Bug#928168: ntp: Wrong path in apparmor profile for samba
Hello,
On Mon, 29 Apr 2019 11:18:27 +0200 Louis van Belle wrote:
> File : /etc/apparmor.d/usr.sbin.ntpd
> Wrong:
> # samba4 ntp signing socket
> /{,var/}run/samba/ntp_signd/socket rw,
>
> Correct:
> # To sign replies to MS-SNTP clients by the smbd daemon in /var/lib/samba
> /var/lib/samba/ntp_signd r,
This line looks wrong (or, more likely, superfluous). According to the
next rule you added, /var/lib/samba/ntp_signd is a directory. However,
to give permissions for a directory, it needs to have a trailing slash:
/var/lib/samba/ntp_signd/ r,
Since things work for you without the additional slash, that means that
you probably don't need this rule.
> /var/lib/samba/ntp_signd/{,*} rw,
This rule includes directory access (directory listing and, thanks to
the w, mkdir).
However I wonder if it really needs to be that broad - the old rule only
allowed access to .../ntp_signd/socket, not to the directory listing,
and not to other files in that directory.
I have a feeling that you wrote these rules based on assumptions, but
I'd prefer to base them on audit.log events ;-)
Can you please provide the AppArmor DENIED (or ALLOWED if running in
complain mode) lines you got for the samba profile?
BTW: Upstream AppArmor prefers to stay backwards-compatible, so it might
be a good idea to allow the "wrong" and the "correct" path - the "wrong"
path probably was correct a while ago, and maybe some people still use it?
(questionmark intentional - you are the samba expert ;-)
> # samba4 winbindd pipe
> /{,var/}run/samba/winbindd r,
Another useless (and superfluous) directory rule without a trailing
slash, please delete it.
BTW: Do you use the samba profiles from upstream AppArmor?
- If so, please contribute your additions upstream at
https://gitlab.com/apparmor/apparmor/
- If not - why? ;-)
Regards,
Christian Boltz
--
what is Office? Is that software I need if I work in an office
(e.g. patience game)? [Stephan Kulow in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#928160: [pkg-apparmor] Bug#928160: apparmor-utils: aa-genprof fails with "ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.lmtp not found"
Hello,
Am Montag, 29. April 2019, 04:39:05 CEST schrieb hoxp18:
> On Buster, "aa-genprof SOMEPROG" fails with the error message.
>
> root# aa-enabled
> Yes
> root# aa-genprof {firefox,firefox-esr,gedit,file,vim} # did each
> actually
>
> ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.lmtp not
> found
>
> The file does not seem to exist in any package.
>
> user$ apt-file search /etc/apparmor.d/local/usr.lib.dovecot.lmtp
>
> nor in /etc
>
> root# find /etc -name usr.lib.dovecot.lmtp -print
>
> I installed apparmor-profiles and apparmor-profiles-extra, too.
/etc/apparmor.d/local/usr.lib.dovecot.lmtp typically gets included by
/etc/apparmor.d/usr.lib.dovecot.lmtp - if you don't have that profile,
please
grep -r usr.lib.dovecot.lmtp /etc/apparmor.d/
I don't know the Debian packaging ("wrong" distribution ;-) but my guess
is that you copied the dovecot profile(s) from /usr/share/apparmor/ to
/etc/apparmor.d/, or got them proposed by aa-genprof, but nobody/nothing
created the local/ includes for them.
As a workaround, you can simply
touch /etc/apparmor.d/local/usr.lib.dovecot.lmtp
(it's an include file where you can add rules specific for your system,
or let it empty if you don't need additional rules)
If you copied more dovecot profiles to /etc/apparmor.d/, you'll probably
need to create local/ include files for each of them. The error messages
will tell you what's missing ;-)
Regards,
Christian Boltz
--
with people like you for sure we would have been still living in a cave
looking for fruits in forests... Fruits are very tasty, why the hell
should we spend time hunting and cooking...
[Alin M Elena in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#924450: [pkg-apparmor] Bug#924450: Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor
Hello, Am Donnerstag, 14. März 2019, 16:11:46 CET schrieb Jonas Meurer: > Done in > https://salsa.debian.org/ddp-team/release-notes/merge_requests/8 Thanks! > So this bugreport can be closed now, right? Yes :-) - but I'll let intrigeri or you do the "paperwork" ;-) Regards, Christian Boltz -- We looked at the recommended way how to do Debian packaging, but found it quite insane. [Michal Hrušecký on https://events.opensuse.org/conference/osc15/proposal/534] signature.asc Description: This is a digitally signed message part.
Bug#924450: [pkg-apparmor] Bug#924450: Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor
Hello, Am Mittwoch, 13. März 2019, 23:31:29 CET schrieb Jonas Meurer: > Thanks a lot to both of you for the corrections. I filed a follow-up > MR to fix this: > > https://salsa.debian.org/ddp-team/release-notes/merge_requests/7 Thanks, now it's nearly correct ;-) Please s/prtrace/ptrace/ if you want to get rid of the "nearly" ;-) Regards, Christian Boltz -- We should actually check if the installation via braille still works. OTOH, it is a tradition that it's always broken by a late RC due to color scheme changes... :-) [Stefan Seyfried in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#924450: [pkg-apparmor] Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor
Hello, Am Mittwoch, 13. März 2019, 07:51:23 CET schrieb intrigeri: > Actually Jonas (Cc'ed) already submitted something: > https://salsa.debian.org/ddp-team/release-notes/merge_requests/6 Looks mostly good to me, with one exception: ... like network access, ... AFAIK [1] support for enforcing network rules is not available in Debian yet, therefore it's probably a good idea to remove the "network" part from the text. If you want to have some items for your list, you can add - capability - rlimit (aka ulimit) - ptrace (since kernel 4.13) - mount (since kernel 4.14) - signal (also since kernel 4.14) Regards, Christian Boltz [1] I'm not a Debian expert, and enjoy having the kernel patch to enforce network rules in the openSUSE kernel since years ;-) -- As you may guess from my comments I do not prefer to ask user to something unless it is really critical like that computer will explode or if beer getting warm. [Josef Reidinger in yast-devel] signature.asc Description: This is a digitally signed message part.
Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration
Hello, I agree that local/ isn't the perfect place. That said... Am Sonntag, 24. Februar 2019, 20:42:55 CET schrieb Mathieu Parent: > Le dimanche 24 février 2019, intrigeri a écrit: > > intrigeri: > >> So I'll add this: > >>#include if exists /etc/apparmor.d/samba/smbd-shares > > > > I mean: > >#include if exists > > I'm OK with this path and understand your rationale. However, I try to > avoid distribution divergence. We had a similar discussion upstream quite a while (years?) ago, but didn't reach an agreement on which path to use. I'm not sure if I like your samba/... path - it's not bad on itsself, but it opens a can of worms. Let's assume for a moment that more programs auto-generate profile sniplets. Do we really want to have one directory for each of them (always holding a single file)? I'm afraid that might produce an interesting forest in /etc/apparmor.d/... Counter-proposal: What about /etc/apparmor.d/autogenerated/$whatever ? That directory could be used by multiple programs. > Christian: any chance that the > opensuse path changes too? We'll have to migrate existing users (and therefore probably have to support both paths in the samba profile for a while). That makes things more interesting[tm], but won't stop me from keeping the path in sync ;-) Another note: update-apparmor-samba-profile does test -e "$profilesniplet" || silentexit "apparmor profile snippet not available" which means you _have to_ ship a (possibly empty) sniplet to ensure the script works. The alternative would be to change that test to something like test -d "/etc/apparmor.d/autogenerated" || silentexit "directory for autogenerated profile sniplets doesn't exist" Regards, Christian Boltz -- > Das ist wieder so ein schöner Popcorn-Thread, zu dem ich > meinen Senf dazu geben will: Popcorn mit Senf :-) [> Jens Nixdorf und Rainer Koenig in suse-linux] signature.asc Description: This is a digitally signed message part.
Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration
Hello,
Am Donnerstag, 21. Februar 2019, 21:26:58 CET schrieb Mathieu Parent:
> As a last-minute fix for buster, I want to fix "#896080 samba: Improve
> AppArmor integration" [SambaAppArmor].
>
> I've prepared the fixes [Diff], inspired by what is done in Suse. But
> they also patch apparmor-profiles [AppArmor-Patch]. This solution does
> not conforms to policy as a file owned by a package could not be
> changed by another one (/etc/apparmor.d/local/usr.sbin.smbd-shares
> owned by apparmor-profiles, changed by samba).
>
> I can add in samba's README the need to add "#include
> " in /etc/apparmor.d/usr.sbin.smbd, but
> maybe you have a better solution? Maybe use dpkg-diversion?
To simplify things, I'd propose to apply a slightly modified version of
https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1
to the usr.sbin.smbd profile in the apparmor-profiles package:
Instead of #include you {c,sh]ould use #include if exists
so that it doesn't matter if local/usr.sbin.smbd-shares exists or
which package creates it.
That might even be an upstream-able solution because it doesn't break
distributions without the autogenerated samba profile sniplet (or without
the package owning that file installed).
The local/usr.sbin.smbd file can then be owned by whatever package
(probably samba, because that also owns the script changing the file).
BTW: Minor nitpicking on
https://salsa.debian.org/samba-team/samba/compare/874f9270b6f743c4d0c3eb1a1a3e1fa814bf25cc...bd4c1577a9b
Can you please change the changelog to "Christian Boltz (openSUSE)"
(instead of "SUSE")? ;-)
Regards,
Christian Boltz
--
[vordefinierte Perlvariablen $_, $>, $[ usw.]
>Steht eigentlich in $§ die Lizenz? ;-)))
$ perl -we 'print $§'
Use of uninitialized value in print at -e line 1.
[> Christian Boltz und David Haller in fontlinge-devel]
signature.asc
Description: This is a digitally signed message part.
Bug#896080: AppArmor/Samba integration in Debian
Hi Mathieu,
Am Donnerstag, 21. Februar 2019, 22:19:34 CET schrieb Mathieu Parent:
> I'm working on AppArmor/Samba integration in Samba and integrated you'
> "update-apparmor-samba-profile" script.
I'm happy to hear that :-)
> I've taken version 1.1, but it silently exists with:
>
> grep -q '^/usr/sbin/smbd (' /sys/kernel/security/apparmor/profiles
> || \ silentexit "smbd profile not loaded"
>
> I don't have the complete path but the profile name in this file:
>
> $ sudo cat /sys/kernel/security/apparmor/profiles | grep smbd
> smbd (enforce)
>
> I don't know much about Apparmor, is this a bug in the script or a
> behavior difference under Debian?
It's a new/changed behaviour of latest upstream AppArmor, and I have to
admit that I completely forgot that this script will need to be adjusted.
Historically, the profiles used the attachment (= path of the binary,
"/usr/sbin/smbd" in this case) as the profile name. This also means that
the profile name changes if you extend the profile to attach to
"/usr/{bin,sbin}/smbd" (which is needed for distributions with merged
/usr/bin/ and /usr/sbin/)
Latest AppArmor switched to using profile names ("smbd") instead, which
makes this easier (and keeps the profile name short and readable).
The switch causes a one-time pain, but ensures that future attachment
changes (like the {bin,sbin} alternation) won't cause additional pain.
Both Debian and openSUSE will have to adjust the
update-apparmor-samba-profile script - for backward compability, the
best way is to grep for both names:
grep '^smbd (\|^/usr/sbin/smbd (' /sys/kernel/security/apparmor/profiles
|| \
silentexit "smbd profile not loaded"
Oh, BTW - thanks for accidently ;-) reporting this openSUSE bug!
I forwarded it to our Samba maintainers in
https://bugzilla.opensuse.org/show_bug.cgi?id=1126377
Please grab the patch from this bugreport to ensure that the Debian and
openSUSE scripts stay in sync.
Regards,
Christian Boltz
--
I am not a Dictator, I can think of no example where I've ordered
anyone to do anything. And I would expect people to stare at me funny
and tell me 'no', if I tried. [Richard Brown in opensuse-project]
signature.asc
Description: This is a digitally signed message part.
Bug#914370: [apparmor] Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc
Hello,
Am Sonntag, 27. Januar 2019, 15:01:40 CET schrieb intrigeri:
> John Johansen:
> > 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.
> > [...]
> > short term: confine users & a trap profile(s) on the /etc/cups dir
>
> I was not able to find any reference to the "trap profile" idea
> in our documentation. Could you please point me in the right
> direction? Thanks in advance!
My guess is that John meant something like that:
/etc/cups/** Cx -> trap,
profile trap {
# intentionally left empty
}
Regards,
Christian Boltz
--
Seriously? If you accused me of verbally abusing the _feature_
(or rather its implementation), I would understand. But I'm not
aware of verbally abusing _people_ (or at least not here, but I
hope you don't really have a microphone near my desk).
[Michal Kubecek in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#917874: [pkg-apparmor] Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many
Hello,
Am Montag, 31. Dezember 2018, 13:04:59 CET schrieb Jakub Wilk:
> * Christian Boltz , 2018-12-31, 12:22:
> >>The init script is broken. The start action fails with:
> >> /etc/init.d/apparmor: 60: shift: can't shift that many
> >
> >This looks like a regression from upstream commit
> >0d5ab43d592245d011b2614e6e20fc7cb851c53c which got backported into
> >the Debian package.
> >
> >
> >The fix is most likely (untested, because I don't see this error on
> >openSUSE):
> I guess it's a bash vs dash thing:
>
>$ bash -c 'shift; echo $?'
>1
>
>$ dash -c 'shift; echo $?'
>dash: 1: shift: can't shift that many
>
> I have /bin/sh pointing to dash (which is the Debian default).
Indeed, that could explain it - openSUSE defaults to bash for /bin/sh,
so it fails silently (and $? gets ignored).
> >- if ! is_apparmor_present ; then
> >+ if ! is_apparmor_present apparmor ; then
>
> Now I get:
>
>Starting AppArmor - failed, To enable AppArmor, ensure your kernel
> is configured with CONFIG_SECURITY_APPARMOR=y then add
> 'security=apparmor apparmor=1' to the kernel command line
>
> It looks like is_apparmor_present() always fails?
Right :-(
(As a sidenote - I wonder why I don't see this failure on openSUSE +
latest rc.apparmor.functions. Intrigeri, do you have an idea what
Debian is doing differently? If in doubt, a sh -x trace might be
interesting to see. A wild guess is that the
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
test in is_apparmor_loaded() might fail for whatever reason so the
"return" shortcut that avoids calling is_apparmor_present() doesn't get
taken.)
Back to the bug - the failure is caused by this test:
[ $? -ne 0 -a -d /sys/module/apparmor ]
Note that the check uses -ne so it expects that $? != 0.
However, the while loop always ends with $? = 0, so the test always
fails.
I'll have to do a little history lesson to explain what happened ;-)
The old version of the function was:
# Test if the apparmor "module" is present.
is_apparmor_present() {
local modules=$1
shift
while [ $# -gt 0 ] ; do
modules="$modules|$1"
shift
done
# check for subdomainfs version of module
grep -qE "^($modules)[[:space:]]" /proc/modules
[ $? -ne 0 -a -d /sys/module/apparmor ]
return $?
}
The function was called in two ways:
is_apparmor_present apparmor
is_apparmor_present apparmor subdomain
so basically /proc/modules was grepped for "apparmor" and "subdomain".
Since AppArmor gets built into the kernel (not as a module) since many
years, that grep never found anything in /proc/modules and returned
with $? = 1. (We could also have called "false" instead of grep - same
result with less CPU cycles ;-)
The cleanup ("because AppArmor wasn't a kernel module since many years")
removed that seemingly superfluous and pointless grep.
However, removing the grep means that $? no longer gets set to 1 (the
while loop ends up with $? = 0), and that means that the function always
fails.
That all said - can you please test with this patch?
--- a/parser/rc.apparmor.functions
+++ b/parser/rc.apparmor.functions
@@ -61,15 +62,9 @@ STATUS=0
# Test if the apparmor "module" is present.
is_apparmor_present() {
- local modules=$1
- shift
+ # TODO: change callers - handing over a parameter is no longer needed
- while [ $# -gt 0 ] ; do
- modules="$modules|$1"
- shift
- done
-
- [ $? -ne 0 -a -d /sys/module/apparmor ]
+ [ -d /sys/module/apparmor ]
return $?
}
The function should now look like this:
is_apparmor_present() {
# TODO: change callers - handing over a parameter is no longer needed
[ -d /sys/module/apparmor ]
return $?
}
> >the only code that still actually does something there is
> >
> >[ -d /sys/module/apparmor ]
>
> With this one-line implementation of is_apparmor_present(), the script
> seems to work, but I get warnings about missing functions:
>
>/etc/init.d/apparmor: 209: /etc/init.d/apparmor:
> aa_log_action_start: not found /etc/init.d/apparmor: 221:
> /etc/init.d/apparmor: aa_log_action_end: not found
That could be a Debian-specific issue - I'll let intrigeri handle this
part ;-) (a quick look indicates that these messages are "only"
annoying, but shouldn't break anything)
Regards,
Christian Boltz
--
Honestly - I ignore every thread Basil or Linda take part in. I wonder
if we can somehow automate that. Perhaps a opensuse-factory-sane list
that is feed by opensuse-factory posts but automatically filters such
threads and posts? [Stephan Kulow in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#917874: [pkg-apparmor] Bug#917874: /etc/init.d/apparmor: 60: shift: can't shift that many
Hello,
Am Montag, 31. Dezember 2018, 10:35:58 CET schrieb Jakub Wilk:
> Package: apparmor
> Version: 2.13.2-2
>
> The init script is broken. The start action fails with:
>
>/etc/init.d/apparmor: 60: shift: can't shift that many
This looks like a regression from upstream commit
0d5ab43d592245d011b2614e6e20fc7cb851c53c
which got backported into the Debian package.
The fix is most likely (untested, because I don't see this error on
openSUSE):
--- a/parser/rc.apparmor.functions
+++ b/parser/rc.apparmor.functions
@@ -252,7 +253,7 @@ mount_securityfs() {
apparmor_start() {
aa_log_daemon_msg "Starting AppArmor"
- if ! is_apparmor_present ; then
+ if ! is_apparmor_present apparmor ; then
aa_log_failure_msg "Starting AppArmor - failed, To enable
AppArmor, ensure your kernel is configured with CONFIG_SECURITY_APPARMOR=y then
add 'security=apparmor apparmor=1' to the kernel command line"
aa_log_end_msg 1
return 1
Jakub, can you please test if the patch fixes the problem?
@intrigeri: do you want to include this as another fix into
https://gitlab.com/apparmor/apparmor/merge_requests/252 ?
If not, I'll submit the above patch as separate merge request.
is_apparmor_present() might also need a round of cleanup, because since
upstream 94ff870f78ad32053392b19b4600b4b5584e3bfb (which removed
grepping /proc/modules for $modules) the only code that still actually
does something there is
[ -d /sys/module/apparmor ]
return $?
but that's another topic ;-)
Regards,
Christian Boltz
--
Foot:
A device for finding furniture in the dark
signature.asc
Description: This is a digitally signed message part.
Bug#900210: Thunderbird AppArmor config breaks stuff with custom $TMPDIR
Hello, Am Dienstag, 20. November 2018, 17:46:27 CET schrieb Stephen Dowdy: > (would be > nice if there was a tool for the desktop to issue notifications in > these cases. maybe there is, but my lack of searching for it has > amazingly not revealed it! ;)) You are probably looking for sudo /usr/sbin/aa-notify -p --display $DISPLAY -w 10 (no idea if /var/log/audit/audit.log is readable for users on Debian - if it is, you can run aa-notify without sudo) > Seems that the latest thunderbird update should honor the aa-complain > status of my system. > > Looking at : /var/lib/dpkg/info/thunderbird.postinst > > I see some logic that looks like i should be using a "disable" link. > That seems like it would be different, however, than just setting it > to 'complain' mode. Right, disable and compain mode are different. The "disable" symlinks will completely disable the profile (it will prevent loading it), which means running Thunderbird unconfined. Complain mode means to load the profile, allow everything [1], and log things that would be denied. Typically complain mode gets set by adding flags=(complain) to the profile. There's an alternative solution - you can create a symlink in /etc/apparmor.d/force-complain/ . While a force-complain symlink makes things easier for package management, there's a known issue: the binary profile cache won't be used for those profiles, so loading the profiles on startup is slower. > (i see that this bug is still in > 'thunderbird', and the apparmor file is dpkg-owned by thunderbird, so > maybe just consider this comment a bug report addition) If the file belongs to Thunderbird, the bugreport also belongs there ;-) (and there are enough AppArmor people in CC) Regards, Christian Boltz [1] There's one exception: explicit "deny" rules will be enforced even in complain mode. -- Last I checked, developers were still human [Bryen M Yunashko in opensuse-project] signature.asc Description: This is a digitally signed message part.
Bug#913020: [Pkg-clamav-devel] Bug#913020: clamd: apparmor denials: cap net_admin, openssl.conf
Hello, I wouldn't be surprised if capability net_admin is triggered by https://bugzilla.opensuse.org/show_bug.cgi?id=991901 (which turned out to be an upstream systemd bug) and fixed by https://github.com/systemd/systemd/pull/10085 I'd recommend to ask the systemd maintainers to apply/backport that patch - it will help to avoid "capability net_admin" requests in several daemons (bassically all that use libsystemd sd_notifyf() etc.) Regards, Christian Boltz -- can you please add a safety check to make sure this doesn't happen again? (for example: the file must have at least 100 lines) cboltz: that check was in place error page was long enough [from #opensuse-admin] signature.asc Description: This is a digitally signed message part.
Bug#882047: [pkg-apparmor] Bug#882047: Bug#882047: apparmor-utils: aa-complain thunderbird fails
Hello,
Am Sonntag, 21. Oktober 2018, 16:49:29 CEST schrieb Christian Boltz:
> As usual if I do some tests, I found more issues:
> - the attachment won't be checked if a profile has a name (so using a
> variable currently doesn't matter ;-)
> - aa-complain first does a "which thunderbird" and then checks with
> the full path, so the profile name also won't match - "thunderbird"
> != "/usr/bin/thunderbird"
> - profile names with alternations (without attachment specification)
> will also not match because aa.py get_profile_filename() doesn't use
> AARE
I worked on this in the last days, and as expected, it really resulted
in "bigger changes". On the positive side, the new code now
distinguishes between profile name and attachment (which avoids
accidential matches and documents what each section of the code is
using) and between active (/etc/apparmor.d/) and inactive/extra
(/usr/share/share/apparmor/extra-profiles) profiles which fixes another
sourse of problems. Oh, and the ProfileList class is covered by unit
tests :-)
All changes survived my testing, but getting more testers always helps.
If you want to test and/or review my changes, you can get them from
https://gitlab.com/apparmor/apparmor/merge_requests/249
Note that variables in the profile name still don't get expanded/
matched.
> Maybe (additionally) matching the aa-complain parameter against the
> profile name would be an easy option/workaround, but I'm undecided if
> this is a good idea because it could also cause false positives -
> opinions?
>
> Or to ask the other way round - assuming you have
> profile foo /bin/bar { ... }
> should aa-complain foo find that profile?
For now, I decided not to support that, so aa-complain will continue to
interpret all parameters as attachment.
Regards,
Christian Boltz
--
> Was muß man tun um auf NTFS schreiben zu können. In der fstab
> hab ich schon auf rw gesetzt. Was muß man noch tun?
1. Beten.
2. MS veranlassen, die Spezifikationen offenzulegen.
3. Weiterbeten.
[> Stefan und Bernd Obermayr in suse-linux]
signature.asc
Description: This is a digitally signed message part.
Bug#882047: [pkg-apparmor] Bug#882047: apparmor-utils: aa-complain thunderbird fails
Hello,
Am Sonntag, 21. Oktober 2018, 09:29:09 CEST schrieb intrigeri:
> With 2.13.1:
>
> # aa-complain thunderbird
> Setting /usr/bin/thunderbird to complain mode.
>
> ERROR: /etc/apparmor.d/usr.bin.thunderbird doesn't contain a valid
> profile for /usr/bin/thunderbird (syntax error?)
>
> … and the profile is not set to complain mode.
I had a look at the profile in apparmor-profiles/ubuntu/18.10.
Vincas found a new, creative way to confuse aa-complain ;-)
@{thunderbird_executable} = /usr/lib/thunderbird/thunderbird{,-bin}
# ...
profile thunderbird @{thunderbird_executable} {
The tools currently don't expand variables when matching the profile
name, therefore it's not surprising that the profile isn't found.
Additionally, checking the profile name "thunderbird" will also fail
because aa-complain first does a "which thunderbird" and then checks
with the full path (tools.py get_next_to_profile()).
As usual if I do some tests, I found more issues:
- the attachment won't be checked if a profile has a name (so using a
variable currently doesn't matter ;-)
- aa-complain first does a "which thunderbird" and then checks with the
full path, so the profile name also won't match - "thunderbird" !=
"/usr/bin/thunderbird"
- profile names with alternations (without attachment specification)
will also not match because aa.py get_profile_filename() doesn't use
AARE
Unfortunately fixing that will need some bigger changes - I'll need to
replace the existing_profiles dict with something better before I can
even start to work on adding AARE support etc. Well, actually that
"something better" will probably handle AARE internally, but I'll still
need to adjust all places that use existing_profiles to use the
"something better" ;-)
Unfortunately "bigger changes" also means that backporting might be
risky :-( - but that still sounds better than keeping all the bugs
mentioned above.
Maybe (additionally) matching the aa-complain parameter against the
profile name would be an easy option/workaround, but I'm undecided if
this is a good idea because it could also cause false positives -
opinions?
Or to ask the other way round - assuming you have
profile foo /bin/bar { ... }
should aa-complain foo find that profile?
> However, "aa-complain /etc/apparmor.d/usr.bin.thunderbird" works just
> fine: it sets both the thunderbird profile and its child gpg profile
> to complain mode :)
Right. Currently this way works much better than giving the executable
as parameter.
> I find this surprising given aa-complain(8) does
> not mention this is possible at all.
Indeed, nice catch ;-)
Can you please open a merge request to update the manpage?
(probably also affects aa-enforce, aa-audit and aa-disable)
While on it, please also adjust the --help of these tools ;-)
Regards,
Christian Boltz
--
I fear that we'll get a shouting match - "my fonts look ugly";
"no, they don't!"; "yes, they do!" :) [Federico Mena Quintero
in https://bugzilla.novell.com/show_bug.cgi?id=220814]
signature.asc
Description: This is a digitally signed message part.
Bug#900210: Thunderbird AppArmor config breaks stuff with custom $TMPDIR
Helllo, Stephen, while we are discussing this, I'd like to give you an easy workaround: Edit /etc/apparmor.d/tunables/alias and add this line: alias /tmp/ -> /run/user/1000/, This will (additionally) allow /run/user/1000/ whenever a profile says /tmp/ If you need a solution that works for all users (and is a bit less strict because it only enforces that the directory name has to start with a digit) alias /tmp/ -> /run/user/[0-9]*/, After adding the alias, reload all AppArmor profiles. The alias will "fix" all profiles, not only the thunderbird profile. Regards, Christian Boltz PS: Can someone who knows the Debian bugtracker better please tag this bug so that we get notifications on pkg-apparmor? -- Most languages allow you to shoot your own foot, C just gives you a tank instead of a handgun ;-) [Cristian Rodríguez in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#904436: [pkg-apparmor] Bug#904436: apparmor-notify: aa-notify is referring to wiki.ubuntu.com by default
Hello, Am Dienstag, 24. Juli 2018, 12:35:44 CEST schrieb Clément Hermann: > aa-notify refers to wiki.ubuntu.com in the notifications. > We should make sure it's using a debian page instead - this is > actually configurable via message_footer in latest upstream version Yes, this is possible now, but would mean to carry a distro-specific patch for notify.conf that (obviously) can never be upstreamed. A more "boring" solution would be to change the upstream default message to point to a page on wiki.apparmor.net ... says the openSUSE AppArmor maintainer ;-) Regards, Christian Boltz -- [ Yes ] [ No ] ... used for harmless errors or simple questions: "It's high time you had your cup of coffee! Would you like your KDE to prepare one for you?" [Lukas Ocilka in opensuse-factory - YaST2 button styleguide] signature.asc Description: This is a digitally signed message part.
Bug#882047: [pkg-apparmor] Bug#882047: apparmor-utils: aa-complain thunderbird fails
Hello,
Am Mittwoch, 13. Juni 2018, 17:00:35 CEST schrieb intrigeri:
> intrigeri:
> > Ben Caradoc-Davies:
> >> On 20/11/17 09:38, Christian Boltz wrote:
> >>> Thanks, but unfortunately I still can't reproduce the problem :-(
> >>> Can you add a bit of debugging code in aa.py, please? […]
> >>
> >> Sure. As requested:
> >>
> >> # aa-complain thunderbird
> >> Setting /usr/bin/thunderbird to complain mode.
> >> looking for /etc/apparmor.d/usr.bin.thunderbird
> >> /usr/bin/thunderbird
> >> reading file /etc/apparmor.d/usr.bin.thunderbird
> >> found RE_PROFILE_START in profile thunderbird
> >> /usr/lib/thunderbird/thunderbird {
> >>
> >> thunderbird None
> >> found RE_PROFILE_START in profile gpg {
> >>
> >> gpg None
> >> found RE_PROFILE_START in profile lsb_release {
> >>
> >> lsb_release None
> >> no profile /etc/apparmor.d/usr.bin.thunderbird /usr/bin/thunderbird
> >>
> >> ERROR: /etc/apparmor.d/usr.bin.thunderbird contains no profile
> >
> > Is this enough to help you debug this problem or do you need more
> > info?
I think it's enough - looks like aa-complain fails to follow
symlinks before looking for the profile :-(
(and sorry for the late reply on this part)
Until I have time to fix this, use
aa-complain /etc/apparmor.d/$whatever
(where $whatever is the profile filename)
> For the record, with 2.13-1 I see a different error:
>
> # aa-complain thunderbird
> Setting /usr/bin/thunderbird to complain mode.
>
> ERROR: Path doesn't start with / or variable: gpg
>
> i.e. aa-complain chokes on the "gpg" named child profile.
That's a known regression in 2.13, unfortunately I didn't have time yet
to check what exactly happens. The upstream bugreport is
https://bugs.launchpad.net/apparmor/+bug/1775591
Regards,
Christian Boltz
--
Vi ist für Leute, deren Hände für Emacs zu klein sind. [Florian Diesch]
signature.asc
Description: This is a digitally signed message part.
Bug#887593: libreoffice-common: apparmor profiles triggers lot of ALLOWED entries
Hello,
Am Freitag, 19. Januar 2018, 13:16:57 CET schrieb Rene Engelhard:
> On Fri, Jan 19, 2018 at 12:52:32PM +0100, Christian Boltz wrote:
> > I'd recommend to use Cx (child profile) rules for gpg so that only
> > gpg (and not libreoffice) get access to ~/.gnupg/
>
> So you basically say this should be
>
> /usr/bin/gpg rmCx,
> /usr/bin/gpgsmrmCx,
I prefer mrCx because rm tends to confuse people not familiar with
AppArmor (no, 'rm' does not mean delete permissions ;-) but in general
you are right.
Note that this will result in two child profiles - one for each binary:
profile /usr/bin/gpg {
# whatever is needed
}
profile /usr/bin/gpgsm {
# whatever is needed
}
If you want to have a common child profile for gpg and gpgsm, use
/usr/bin/gpg mrCx -> gpg,
/usr/bin/gpgsmmrCx -> gpg,
profile gpg {
# whatever is needed
}
> At least that is how I read
> https://github.com/coderbunker/linux/wiki/Apparmor-how-to
I didn't read all text on that page, but on a quick look it looks good.
Actually it *must* be good because it links to my presentation ;-))
(If you prefer to only read the slides, you can download them from
https://blog.cboltz.de/archives/70-openSUSE-Conference-2016.html )
> Something special for .gnupg then? Right now there is
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=c6a19889e91f2
> 585453636667e3d5779b153ab86:
nice[tm]
+ # there is abstractions/gnupg but that's just for gpg1...
In such cases, it's a good idea to open a bugreport upstream [1] or to
send a merge request on gitlab to get the abstraction updated ;-)
You might still want/need to add it in your profile as a temporary
solution until everybody has a new-enough abstraction.
> owner @{HOME}/.gnupg/* r,
Indeed, giving gpg read access to all files in ~/.gnupg/ makes sense.
I'd be very surprised if this directory contains a file gpg should not
be allowed to read ;-)
Regards,
Christian Boltz
[1] actually a bugreport against the Debian AppArmor package also works.
Even if I don't use Debian, I read all AppArmor-related Debian
bugreports.
--
Tja, in der Urzeit war vieles einfacher.
Da musste man sich nicht um die korrekte Uhrzeit seiner Rechner-Uhr
kümmern, weil es noch keine Mailing-Listen gab. ;-)
[Carsten Neumann in opensuse-de]
signature.asc
Description: This is a digitally signed message part.
Bug#887593: libreoffice-common: apparmor profiles triggers lot of ALLOWED entries
Hello,
just a quick note:
> + /usr/bin/gpg rmix,
> + /usr/bin/gpgsmrmix,
and in a later comment
> Thinking about it, we probably also would need owner
> "@{HOME}/.gnupg/* rwk," then for gpg. This gets interesting...
I'd recommend to use Cx (child profile) rules for gpg so that only gpg
(and not libreoffice) get access to ~/.gnupg/
Regards,
Christian Boltz
--
| $ rpm -q --whatrequires kernel
| no package requires kernel
Ach ja, dascha interessant! Kein RPM braucht das? Ja wie? Dann kann
ich das RPM ja also beruhigt loeschen? Braucht ja keiner... *lol*
[David Haller in suse-linux]
signature.asc
Description: This is a digitally signed message part.
Bug#887591: [pkg-apparmor] Bug#887591: apparmor-profiles: dovecot capname="dac_read_search"
Hello, Am Donnerstag, 18. Januar 2018, 17:56:58 CET schrieb intrigeri: > If you're annoyed by these warnings in the logs you can fully disable > the profile with aa-disable. If you actually want to confine dovecot > with AppArmor, great: please report this bug upstream > (https://launchpad.net/apparmor); the fix should be a one-liner. I'm reading the Debian bugs (besides Ubuntu, openSUSE and of course upstream bugs), so there's no need for additional paperwork for such a small bug ;-) I just submitted a merge request with the updated profile: https://gitlab.com/apparmor/apparmor/merge_requests/55 Regards, Christian Boltz -- you are expected to know what you're doing (e.g. you're a test script). [Steve Beattie in apparmor] signature.asc Description: This is a digitally signed message part.
Bug#845232: [pkg-apparmor] Bug#845232: Maybe add README.Debian
Hello, Am Donnerstag, 7. Dezember 2017, 09:40:04 CET schrieb intrigeri: > - disabling use_group in notify.conf, so this (mostly useless AFAICT) > check does not harm UX Can you please submit this upstream? I agree that this check is useless - the relevant "check" is if someone has permissions to a) read the audit.log or b) run aa-notify with sudo. Regards, Christian Boltz -- Hardcore ultrageek sysadmins who really really really know that they are doing [...] will probably never use YaST or will never admit they do it, at least. :-) [Ancor González Sosa in yast-devel] signature.asc Description: This is a digitally signed message part.
Bug#882047: [pkg-apparmor] Bug#882047: Bug#882047: apparmor-utils: aa-complain thunderbird fails
Hello,
Am Samstag, 18. November 2017, 22:25:40 CET schrieb Ben Caradoc-Davies:
> On 19/11/17 07:47, Christian Boltz wrote:
> > Can you please send (to me or the bugreport) your
> > /etc/apparmor.d/usr.bin.thunderbird profile so that I have the
> > correct profile to test?
>
> Attached.
Thanks, but unfortunately I still can't reproduce the problem :-(
Can you add a bit of debugging code in aa.py, please?
Search for
def get_profile_flags(filename, program):
and add the lines marked with "# added" (or just replace the function
with the code below)
def get_profile_flags(filename, program):
# To-Do
# XXX If more than one profile in a file then second one is being ignored
XXX
# Do we return flags for both or
print('looking for', filename, program) # added
flags = ''
with open_file_read(filename) as f_in:
print('reading file %s' % filename) # added
for line in f_in:
if RE_PROFILE_START.search(line):
matches = parse_profile_start_line(line, filename)
profile = matches['profile']
flags = matches['flags']
print('found RE_PROFILE_START in %s' % line) # added
print(profile, flags) # added
if profile == program or program is None:
print('match, returning flags') # added
return flags
print('no profile', filename, program) # added
raise AppArmorException(_('%s contains no profile') % filename)
Then run aa-complain thunderbird again and send the output.
Regards,
Christian Boltz
--
> +1. sysvinit vs systemd is the new emacs vs vim.
>
>
>
heh, the difference is that systemd still doesnt implement a whole OS
yet :-D [> Will Stephenson and Cristian Rodríguez in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#882047: [pkg-apparmor] Bug#882047: apparmor-utils: aa-complain thunderbird fails
Hello, Am Samstag, 18. November 2017, 02:48:30 CET schrieb Ben Caradoc-Davies: > # aa-complain thunderbird > Setting /usr/bin/thunderbird to complain mode. > > ERROR: /etc/apparmor.d/usr.bin.thunderbird contains no profile That means it fails in the get_profile_flags() function in aa.py (the only place where this error message is used). I just tried myself (by fetching the profile from packages.debian.org and testing it on my openSUSE system ;-) but get a different error message (yes, there are known issues with named profiles) so your profile probably differs from what I found. Can you please send (to me or the bugreport) your /etc/apparmor.d/usr.bin.thunderbird profile so that I have the correct profile to test? As a workaround, you can use aa-complain /etc/apparmor.d/usr.bin.thunderbird Another workaround is to create a symlink in /etc/apparmor.d/force-complain > aa-complain only works if profile is named precisely for executable > https://bugs.launchpad.net/apparmor/+bug/1128468 That's an old bug that was fixed long ago. It's unrelated, even if it looks somewhat similar ;-) Regards, Christian Boltz -- Microsoft is a cross between The Borg and the Ferengi. Unfortunately they use Borg to do their marketing and Ferengi to do their programming. [Simon Slavin in the SDM] signature.asc Description: This is a digitally signed message part.
Bug#880502: [pkg-apparmor] Bug#880502: [pkg-lxc-devel] Bug#880502: lxc: cannot start container with kernel 4.13.10
Hello, seeing the AppArmor denials would be helpful to get this fixed ;-) Please either grep -i apparmor /var/log/syslog or, if you have auditd installed, check /var/log/audit/audit.log For more details, see https://wiki.debian.org/AppArmor/Debug Regards, Christian Boltz -- > Anyway, what does our mission statement say? > > "Have a lot of fun..." [> Per Jessen and Greg KH in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#878203: [pkg-apparmor] Bug#878203: Bug#878203: Bug#878203: AA breaks libvirt when running with kernel 4.13
Hello,
Am Montag, 23. Oktober 2017, 09:14:52 CEST schrieb intrigeri:
>> 2017-10-11T14:43:54.683220+02:00 pluto kernel: [ 355.112941] audit:
> > type=1400 audit(1507725834.681:55): apparmor="DENIED"
> > operation="open"
> > profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> > name="/proc/684/cmdline" pid=3154 comm="qemu-system-x86"
> > requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> Shall we silence the denial or allow it
No idea about that, but...
> (possibly prefixed with "owner" to avoid increasing the attack
> surface too much)?
Have a look at the denial again - fsuid != ouid, so you can't use an
owner rule.
Also, the pid is not the same as in the /proc/*/cmdline name, so please
use @{pids}, not the (planned-to-be-restricted-to-own-pid) @{pid}
variable.
Regards,
Christian Boltz
--
Ein Killfile ist der natürliche Lebensraum von Trollen und Elchen. Wenn
sich jemand zu ihnen gesellt, entstehen lustige Geräusche, wie PLONK.
Manchmal machts auch PLATSCH, wenn der Lebensraum bereits überbevölkert
ist. [David Dahlberg]
signature.asc
Description: This is a digitally signed message part.
Bug#877581: [pkg-apparmor] Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice
Hello, Am Donnerstag, 12. Oktober 2017, 18:18:53 CEST schrieb Vincas Dargis: > Could you clarify, why Ubuntu should have issues, if they had network > mediation before? It turned out that the added "network unix dgram/stream" rules are not really needed. Let me explain ;.-) In theory apparmor_parser should downgrade the "unix" rules in abstractions/base to "network unix" rules (when using Kernel < 4.15), which allows more than "network unix dgram/stream". In practise this rule downgrade was broken in apparmor_parser, and got fixed in AppArmor 2.11.1, 2.10.3 and 2.9.5. So once you update apparmor_parser to one of these versions, profiles that include abstractions/base (which basically means all profiles) should no longer need the "network unix dgram/stream" rules. This also explains why Ubuntu users didn't see this problem - their kernel supports 'unix' rules since years, so the rule downgrade to 'network unix' was not needed. Note that the patch discussed in this bugreport adds a few other rules - those will still be needed. Regards, Christian Boltz -- > All cats purr at 28hz. I think your cats need tuning - according to a couple of quick measure- ments on a recently calibrated reference cat, the dominant frequency of a correctly adjusted cat should be 12Hz +/-20%. [Lionel Lauer] signature.asc Description: This is a digitally signed message part.
Bug#878203: [pkg-apparmor] Bug#878203: Bug#878203: AA breaks libvirt when running with kernel 4.13
Hello,
there were some more profile changes done - first in openSUSE [1], but
AFAIK they were already upstreamed.
I had a quick look at the log - most denials are fixed with the latest
upstream profile, so I'd recommend to grab that one.
I noticed one denial that probably isn't covered by the upstream profile
yet:
apparmor="DENIED" operation="open" profile="libvirt-c6ae5f8d-
e017-484d-9176-96b0e079c66d" name="/proc/726/cmdline" pid=6188
comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=114
ouid=0
That translates to
/@{PROC}/@{pids}/cmdline r,
and should probably go into abstractions/libvirt-qemu
Regards,
Christian Boltz
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1058847 and
https://bugzilla.opensuse.org/show_bug.cgi?id=1060860
--
In asynchron-verteilten Umgebungen mußt Du gegen jede einzelne Regel
Deiner Datenbankvorlesung verstoßen. [Kris Köhntopp]
signature.asc
Description: This is a digitally signed message part.
Bug#872266: [pkg-apparmor] Bug#872266: apparmor-profiles-extra: Disable profiles before uninstalling them
Hello, Am Samstag, 9. September 2017, 20:24:40 CEST schrieb intrigeri: > Clément Hermann: > > apparmor profiles should be removed with `apparmor_parser -R > > ` before uninstallation (prerm). > > Agreed, good catch. I'm not sure if we want to do that only when > purging, or on "normal" removal as well. What do you think? > > Ubuntu/OpenSUSE people, what do you think about 1. the general idea of > unloading profiles when de-installing the package that ships them; TL;DR: I'd strongly recommend *not* to unload profiles when de-installing a package. Both unloading and not unloading a profile can cause trouble, so let me describe both situations: If you don't unload the profile on package uninstall, there's a risk that the profile gets accidently applied to a newly installed binary with the same path. An example might be /usr/sbin/sendmail when replacing sendmail with postfix. (Note that I didn't check if there's a profile for this binary, it's just one of the very few examples I can think of.) An additional condition is that the new package doesn't include an AppArmor profile - otherwise the still-loaded profile would be replaced. So all in all, this can happen, but is very unlikely IMHO. OTOH, if you unload a profile, and a program from this package is still running, unloading the profile means to remove the confinement from the running program. In other words: the still-running program can now do whatever it wants. I prefer to error out on the safe side, therefore I recommend not to unload profiles on package uninstallation. The security risks this prevents clearly outweight the (unlikely) problems with still-loaded profiles. BTW: I assume there isn't a "killall -9" for every binary shipped in the package in prerm, right? ;-) Unloading the profiles wouldn't be too different to that IMHO. > 2. unload on removal vs. on purge? Sorry, EWRONGPACKAGEMANAGER ;-) Regards, Christian Boltz -- Last I checked, developers were still human [Bryen M Yunashko in opensuse-project] signature.asc Description: This is a digitally signed message part.
Bug#874873: [pkg-apparmor] Bug#874873: Pick the best AppArmor introduction docs and advertise them better
Hello, AppArmor Adminstration Guide http://www.novell.com/documentation/apparmor/apparmor201_sp10_admin/index.html?page=/documentation/apparmor/apparmor201_sp10_admin/data/book_apparmor_admin.html looks like a very outdated version of what is the openSUSE Security Guide nowadays. Please replace that link with openSUSE Security Guide (AppArmor chapter) https://doc.opensuse.org/documentation/leap/security/html/book.security/part.apparmor.html I reviewed that chapter two years ago - and its author probably still hates me for that ;-) Since then, AppArmor didn't change too much, therefore I'd expect that it's still correct and up to date. It also includes a complete reference to the profile language (as of two years ago, so the "new" rule types like dbus and ptrace are still missing). Regards, Christian Boltz -- Hmm.. Good point Adrian. I should get used to that thing close to my keyboard... how did you call it? Mouse? :-) [Dominique Leuenberger in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hello, Am Montag, 21. November 2016, 15:13:55 CET schrieb Seth Arnold: > On Sun, Nov 20, 2016 at 05:41:09PM +0100, Christian Boltz wrote: > > [patch] Update abstractions/gnome with versioned gtk paths > > > > I propose this patch for trunk, 2.10 and 2.9. > > Acked-by: Seth Arnold <seth.arn...@canonical.com> > > Acked for all three Commited to bzr trunk r3588, 2.10 branch r3365 and 2.9 branch r3033, which means the fix will be included in AppArmor 2.11, 2.10.2 and 2.9.4 whenever we release them ;-) Updating abstractions/gnome should be enough to get this bug fixed. I don't see a need to update the icedove profile. Regards, Christian Boltz -- Actually the _real_ "minimal package set" is having no package at all because having no package at all resolves all dependencies of the packages and there is no package left someone might claim to be unneeded. [Robert Schiele in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hello,
(adding back u. to CC - sorry, I didn't realize mails for this bugreport
don't get delivered to pkg-apparmor when cleaning up the recipients)
Am Sonntag, 20. November 2016, 13:00:00 CET schrieb anonym:
> At least on my system, I have
>
> /usr/lib/x86_64-linux-gnu/gtk-2.0
> /usr/lib/x86_64-linux-gnu/gtk-3.0
>
> and nothings else, so your suggseted change looks good to me.
> > + /usr/share/themes/** r,
> >
> > This is already included in abstractions/gnome, so I wonder why you
> > needed to add it.
>
> Sorry! It is not needed (and the explanation for why I included it by
> mistake is just to boring to share here).
Nothing is too boring (and often someone can learn from it), so I'm all
ears ;-)
> So, in the end, your suggested update to abstractions/gnome (the gtk
> path) seems like the only thing needed, and indeed better than my
> patch.
Thanks for the feedback!
So here's the patch I hereby propose upstream:
[patch] Update abstractions/gnome with versioned gtk paths
I propose this patch for trunk, 2.10 and 2.9.
[ abstractions-gnome.diff ]
=== modified file 'profiles/apparmor.d/abstractions/gnome'
--- profiles/apparmor.d/abstractions/gnome 2016-11-06 09:23:51 +
+++ profiles/apparmor.d/abstractions/gnome 2016-11-20 16:31:56 +
@@ -22,6 +22,8 @@
/etc/gtk/* r,
/usr/lib{,32,64}/gtk/** mr,
/usr/lib/@{multiarch}/gtk/**mr,
+ /usr/lib{,32,64}/gtk-[0-9]*/** mr,
+ /usr/lib/@{multiarch}/gtk-[0-9]*/** mr,
/usr/share/themes/ r,
/usr/share/themes/**r,
Regards,
Christian Boltz
--
> I also prefer realnames. But if people want to use a _spellable_
> alias, it's ok for me too.
> However, I hate aliases like "fE3,x7~5X" ;-)
Noone should use his/her password as a mail name ;-)
[> Christian Boltz and meister(at)netz00.com in opensuse]
signature.asc
Description: This is a digitally signed message part.
Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes
Hello,
Am Samstag, 19. November 2016, 12:43:00 CET schrieb u:
> anonym:
> > As a KDE user I want Icedove to look like a native application
> > despite it using GTK, which can be achieved with the
> > gtk2-engines-pixbuf package and some gtk*-engines-* package (e.g.
> > gtk3-engines-breeze). However, the current Icedove AppArmor profile
> > blocks the paths used by these packages.
> Looks good.
>
> > The attached patch fixes the profile for me. A proper solution for
> > AppArmor upstream might be to add the new lines to the appropriate
> > abstraction file (perhaps abstractions/gnome?).
>
> I've put the upstream list and the original author of the profile in
> Cc:. @Upstream, what do you think?
Looks good, and it would indeed be a candidate for abstractions/gnome.
Some notes and questions:
+ /usr/lib/@{multiarch}/gtk-*/*/engines/libpixmap.so* mr,
does not match the openSUSE patchs. Therefore I propose to also add
/usr/lib*/gtk-*/*/engines/libpixmap.so* mr,
to make this a cross-distro compatible change ;-)
Looking at the gnome abstraction again, I see
/usr/lib{,32,64}/gtk/** mr,
/usr/lib/@{multiarch}/gtk/**mr,
Both directories don't exist on my openSUSE system. Instead there is
/usr/lib64/gtk-2.0/ and /usr/lib64/gtk-3.0/. Maybe we should update
these rules to match the versioned paths (and, as a side effect, include
libpixmap.so)? That would mean to add
/usr/lib{,32,64}/gtk-[0-9]*/** mr,
/usr/lib/@{multiarch}/gtk-[0-9]*/**mr,
Does /usr/lib{,32,64}/gtk/ and/or /usr/lib/@{multiarch}/gtk/ still
exist on Debian?
(bzr blame says these lines of the gnome abstractions were last touched
in 2011, so things might have changed since then ;-)
+ /usr/share/themes/** r,
This is already included in abstractions/gnome, so I wonder why you
needed to add it.
Regards,
Christian Boltz
--
I just fixed your bug, now you need to find something else to bitch
and flame about ;P
[Cristian Rodriguez on
http://seifesrants.blogspot.de/2013/05/the-systemd-journal-is-broken-piece-of.html]
signature.asc
Description: This is a digitally signed message part.
Bug#844929: [pkg-apparmor] Bug#844929: apparmor: FTBFS: Tests failures
Hello,
Am Samstag, 19. November 2016, 07:55:54 CET schrieb Lucas Nussbaum:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
The more relevant part is probably:
FAIL: test_python.py
Traceback (most recent call last):
File "./test_python.py", line 16, in
import LibAppArmor as libapparmor
File
"/<>/libraries/libapparmor.python2.7/swig/python/build/lib.linux-x86_64-2.7/LibAppArmor/__init__.py",
line 21, in
_LibAppArmor = swig_import_helper()
File
"/<>/libraries/libapparmor.python2.7/swig/python/build/lib.linux-x86_64-2.7/LibAppArmor/__init__.py",
line 20, in swig_import_helper
return importlib.import_module('_LibAppArmor')
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _LibAppArmor
FAIL test_python.py (exit status: 1)
This is caused by changes in newer swig versions and was already fixed
upstream in trunk r3582 and 2.10 branch r3359.
Regards,
Christian Boltz
--
Sitzstreik
analoger Denial of Service-Angriff gegen ein Gebäude
[Jacob Appelbaum,
http://netzpolitik.org/2012/jacob-appelbaum-ruft-zu-mehr-digitalem-aktivismus-auf-wir-sind-alle-anonymous/]
signature.asc
Description: This is a digitally signed message part.
Bug#843461: apparmor: Support usrmerge
Hello,
Am Dienstag, 8. November 2016, 15:06:50 CET schrieb intrigeri:
> Christian: did OpenSUSE go through something like usrmerge? If you
> did, how did you handle it?
openSUSE moved lots of binaries, but not all from /{s,}bin/ to
/usr/{s,}bin/
> Besides, they
> significantly increase policy compilation time.
I never benchmarked that - do you have some numbers?
> But I recommend against using alias rules by default, system-wide, in
> a distribution like Debian: they cause too much action at a distance
> and subtle breakage, which will make it hard for users to debug issues
> themselves, and for us to understand their bug reports.
Right. Shipping aliases _will_ confuse users and make things harder.
> So the only option I can think of is going through all profiles we
> ship, and making sure that every instance of /bin becomes /{usr/,}bin.
That's exactly what I did - for example, the /bin/ping profile became
/{usr/,}bin/ping. These changes are all in the upstream bzr since a long
time.
To keep the profile names readable, I'd recommend to use something like
profile ping /{usr/,}bin/ping
(and yes, exactly for the ping example, I didn't do that ;-)
> This seems doable since we ship relatively few profiles, spread over
> a relatively small number of packages, and they contain few /bin/*
> permissions. A quick look points to a sid system gives me these
> packages needing such changes: evince, apparmor-profiles-extra,
> libvirt-daemon-system, cups-daemon, apparmor-profiles, apparmor,
> telepathy-mission-control-5 (non-exhaustive list). Thankfully, this
> will benefit all other distros as well, and could even been done
> collaboratively if anyone else than Debian is interested :)
That reminds me of the profile repo which would make sharing profiles
and cross-contributions much easier ;-)
I know everybody is always busy etc., so maybe we can start with a small
step like a place where I can find all profiles Debian ships at one
location?
For openSUSE, I have the apparmor-profiles-collector package at
http://download.opensuse.org/repositories/home:/cboltz/openSUSE_Factory/noarch/
[1]
You can unpack the RPM package with rpm2cpio $file | cpio -dium
or browse it using mc ;-)
Currently, I simply copy the profiles and record from which package they
come. If you are interested in my (trivial) script doing this, have a
look at
https://build.opensuse.org/package/show/home:cboltz/apparmor-profile-collector
I'm sure it would be trivial to get "Debian" and "openSUSE" directories
in the apparmor-profiles git repo. Even without all the metadata etc.
we discussed, this would be much more useful than the current state.
Regards,
Christian Boltz
[1] it will probably have to move to a separate repo to avoid that it
collects the profiles from the latest apparmor-profiles package in
this repo instead of the apparmor-profiles used in each
distribution, but this "only" affects profiles from AppArmor bzr.
--
Life used to be simpler when apple and blackberry were just fruits!
[from https://bugzilla.novell.com/quips.cgi]
signature.asc
Description: This is a digitally signed message part.
Bug#835826: [pkg-apparmor] Bug#835826: apparmor-profiles: usr.lib.dovecot.imap issue?
Hello, Am Sonntag, 28. August 2016, 18:49:15 CEST schrieb Félix Sipma: > Aug 28 18:42:04 laptop audit[8899]: AVC apparmor="ALLOWED" > operation="getattr" profile="/usr/lib/dovecot/imap//null-8b//null-8c" > name="/home/user/mail/dovecot.index.log" pid=8899 comm="imap" > requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 This (especially the "//null-*" child profiles [1]) means you'll need aditional exec rules. To find out what exactly gets executed, can you please post a bigger section of your audit log, or even the full log? I'm especially looking for a line with operation="exec" profile="/usr/lib/dovecot/imap" (without any "//null-*" in the profile name) Note that there are two exec levels involved, so we might need to add more than one an exec rule. This also means that posting your full audit log (or at least everything dovecot-related after the exec event described above) can avoid an additional round of updating the profile and sending fresh logs ;-) Regards, Christian Boltz [1] null-* are temporary profiles for execs that are not permitted in the profile yet (and will obviously only be created for profiles in complain mode - in enforce mode, unknown execs gets denied) -- Kann man KDE1 Anwendungen benutzen? Ich kenne nur noch zusätzlich KDE2, was ich schrecklich finde, da es sich entweder aufhängt oder langsam ist. Manchmal auch beides zusammen. KDE3 schafft es wenigstens den Krashmanager anzuzeigen, wenn ein Programm abstürzt. ;-) [Ferdinand Ihringer in suse-linux] signature.asc Description: This is a digitally signed message part.
Bug#805002: [pkg-apparmor] Bug#805002: libvirt-client: "virsh attach-disk" fails with AppArmor enabled
Hello,
Am Samstag, 30. Juli 2016, 14:06:48 CEST schrieb intrigeri:
> Guido Günther:
> >/sbin/apparmor_parser -r
> >/etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-42fe-b1a2-06830752
> >843a
> >virsh qemu-monitor-command wheezy --pretty --cmd
> >'{"execute":"human-monitor-command","arguments":{"command-line":
> >"drive_add dummy file=/var/li
> AFAIK an already running process is not affected by changes to its
> AppArmor profile, as "Profiles are applied to a process at exec(3)
> time" (apparmor(7)).
>
> So I don't see how we can make virsh attach-disk work under AppArmor
> without either rebooting the guest to take into account the updated
> profile, or extending the profile in advance (so that it allows access
> to all disks that one may want to attach later to a domain).
>
> > I have also observed that aa-{disable,complain} dont affect running
> > VMs but this might just an omission in the documentation.
>
> I think this is somewhat documented in the manpage as quoted above.
I think you are misreading the documentation here ;-)
"Profiles are applied to a process at exec(3) time" (apparmor(7))
means: If you start a process unconfined (without an AppArmor profile) and
load a profile later, that process will stay unconfined (unless exec(3)
gets called).
Also if you unload a profile and then load it again, running processes
will become and stay unconfined.
OTOH, if you already have a profile loaded, start a process and then
reload the modified profile, it will be applied instantly.
Note that there were bugs both in apparmor_parser and the kernel that
broke reload and could cause the problem you described. So please check
if Debian has the fixes in apparmor_parser (likely, because this was fixed
a while ago) and the kernel (less likely because that patch is quite
new). If in doubt, John should be able to point you to the relevant
patches.
Regards,
Christian Boltz
--
> ich übenehme dann freiwillig die Rolle des Dussels des Tages.
Ne ne mein Freund, den Titel lasse ich mir nicht nehmen, mit meiner
DSL-Geschichte... Dusseliger kann man sich nicht anstellen...
[> Ralf Prengel und Dieter Soost in suse-linux]
signature.asc
Description: This is a digitally signed message part.
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
Hello, Am Sonntag, 5. Juni 2016, 13:34:19 CEST schrieb Guido Günther: > On Sat, Jun 04, 2016 at 06:38:46PM +0200, Christian Boltz wrote: > > deny rules are enforced even if you switch the profile to complain > > mode, and don't leave any log events behind. You might want to > > change them to"audit deny" temporarily to get log events (with > > AUDIT). > > I did not know. Thanks! IMHO this needs to be mentioned in the > aa-complain manpage to fulfill the "no PhD in computer science needed > for" promise. Good point. I just commited an updated manpage upstream (will be in 2.11, 2.10.2 and 2.9.4 whenever they get released). > The issue turned out to be environment scrubbing: > > https://www.redhat.com/archives/libvir-list/2016-June/msg00117.html > > but I think the issue is still valid: getting an idea what gets > dropped to the floor is too hard atm. With complain mode I'd exepct: > > * denials logged by default The whole point of deny rules is to silence the logging (except if they also have the audit keyword). You can enable the logging by adding the audit keyword, but the general rule is not to log anything that is already handled (allowed or denied) in the profile. > * a way to audit calls to subprocesses indicating whether the > environment was scrubbed or not You'll get this information by reading the profile ;-) It already had "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with environment scrubbing. I'm CC'ing another upstream developer, but I wouldn't be surprised if he tells you the same ;-) @John: Do you have a different opinion on Guido's points? > * other stuff I might not even know about yet like DBus denials … Actually I can't tell you too much about DBus because only the Ubuntu kernel has DBus support for AppArmor (it's not upstreamed yet), and I'm using openSUSE ;-) Regards, Christian Boltz [1] I'm not sure if this rule (and the other broad PUx rules) are a good idea [2], but a) I don't know libvirtd good enough to judge on it and b) that's a totally different topic ;-) [2] These PUx rules allow to execute _all_ programs, and most of them unconfined (except if a profile for this program exists). I slightly ;-) doubt libvirtd needs to execute all of them... -- [bugzilla is] being as co-operative as a 2 legged donkey pulling a 10 ton tractor under attack by an army of bees [Richard Brown in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#826218: [pkg-apparmor] Bug#826218: Complain still interferes
Hello, Am Samstag, 4. Juni 2016, 15:04:04 CEST schrieb Guido Günther: > Well, there are no DENIED messages - that's the puzzling part and the > reason for this bug. The should be a all also contain "audit" and end > up in dmesg so my grep expression should have caught them Does the profile contain any deny rules? If unsure, run apparmor_parser -pq /etc/apparmor.d/the.profile.to.check | grep deny (this will print out the profile with all includes merged in) deny rules are enforced even if you switch the profile to complain mode, and don't leave any log events behind. You might want to change them to"audit deny" temporarily to get log events (with AUDIT). BTW: If you switch the profile to complain mode, the messages will contain ALLOWED instead of DENIED. Regards, Christian Boltz PS: random sig ;-) -- [AppArmor] Unlike SELinux, it does not require a PhD in computer security to get it working... [Peter Czanik in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#822349: [pkg-apparmor] Bug#822349: does not enable policy if it's the system's first
Hello, Am Samstag, 23. April 2016, 19:57:37 CEST schrieb Peter Palfrader: > If a package ships an apparmor policy, and it's the first policy on > the system, then it's not getting enabled during postinst configure, > causing the service to fail to start: > I think the problem is that, without any policies loaded, aa-status > enabled exits with exit code 2, and thus the postinst doesn't enable > the service: FYI: Starting with AppArmor 2.11 beta, there is a new small aa-enabled binary (in the "binutils" directory). aa-enabled will give you the exit codes known from aa-status --enabled, with the exception that it will exit with 0 instead of 2 if AppArmor is enabled, but no profile is loaded (= exactly what you want here ;-) Therefore the long-term solution is to use aa-enabled instead of aa-status --enabled. Also note that in the future (not in 2.11) aa-status might need some of the apparmor python modules, which will make it less lightweight. Regards, Christian Boltz -- > Wer kennt eine gute Beschreibung, am besten in deutsch die die > Installion und Einrichtung von mysql und php beschreibt? > Bitte mehr als nur die Anwort: "Ich" ok, kein problem. google. [>Marcel Stein u. Michael Meyer in suse-linux] signature.asc Description: This is a digitally signed message part.
Bug#809649: [pkg-apparmor] Bug#809649: ssh login not possible when setting usr.sbin.sshd to enforced
Hello,
Am Samstag, 2. Januar 2016 schrieb Evgeni Golov:
> using /usr/share/doc/apparmor-profiles/extras/usr.sbin.sshd with
> current sshd will make the system not accepting logins anymore.
>
> The following patch fixes it:
I just tested on openSUSE and got similar results, but also some small
differences:
- I additionally need capability sys_ptrace,
- I don't need w access to /var/log/btmp (but nevertheless it makes
sense to allow it)
- while on it, I changed most @{PROC}/@{pid} to use owner restrictions -
and found out that @{PROC}/*/fd/ r, is using the pid of the shell
started for the just-logged in user, so I changed it to use @{pids}
(and didn't add the owner restriction)
My version of the patch is:
=== modified file 'profiles/apparmor/profiles/extras/usr.sbin.sshd'
--- profiles/apparmor/profiles/extras/usr.sbin.sshd 2013-01-05 06:31:00
+
+++ profiles/apparmor/profiles/extras/usr.sbin.sshd 2016-01-02 13:44:20
+
@@ -2,6 +2,8 @@
#
#Copyright (C) 2002-2005 Novell/SUSE
#Copyright (C) 2012 Canonical Ltd.
+#Copyright (C) 2016 Christian Boltz
+#Copyright (C) 2016 Evgeni Golov
#
#This program is free software; you can redistribute it and/or
#modify it under the terms of version 2 of the GNU General Public
@@ -26,14 +28,17 @@
capability sys_resource,
capability sys_tty_config,
capability net_bind_service,
+ capability net_admin,
capability chown,
capability fowner,
capability kill,
capability setgid,
capability setuid,
capability audit_control,
+ capability audit_write,
capability dac_override,
capability dac_read_search,
+ capability sys_ptrace,
/dev/ptmx rw,
/dev/urandom r,
@@ -48,13 +53,16 @@
@{PROC}/@{pid}/oom_adj rw,
@{PROC}/@{pid}/oom_score_adj rw,
/usr/sbin/sshd mrix,
- /var/log/btmp r,
+ /var/log/btmp rw,
/{,var/}run w,
/{,var/}run/sshd{,.init}.pid wl,
- @{PROC}/@{pid}/fd/ r,
- @{PROC}/@{pid}/loginuid w,
- @{PROC}/@{pid}/limits r,
+ @{PROC}/cmdline r,
+ @{PROC}/1/environ r,
+ @{PROC}/@{pids}/fd/ r, # pid of the just-logged in user's shell
+ owner @{PROC}/@{pid}/loginuid rw,
+ owner @{PROC}/@{pid}/limits r,
+ owner @{PROC}/@{pid}/uid_map r,
# should only be here for use in non-change-hat openssh
# duplicated from EXEC hat
Can you please test with this patch? (In theory the added owner
restrictions could cause denials.)
I'll submit the patch upstream as soon as soon as you report back ;-)
Regards,
Christian Boltz
--
"What is the purpose of the systemd journal service?"
Answer: Forwarder for external or on-system real syslog service.
[Yamaban in opensuse-factory]
Bug#809649: [pkg-apparmor] Bug#809649: Bug#809649: ssh login not possible when setting usr.sbin.sshd to enforced
Hello,
Am Samstag, 2. Januar 2016 schrieb Evgeni Golov:
> On Sat, Jan 02, 2016 at 02:52:47PM +0100, Christian Boltz wrote:
> > I just tested on openSUSE and got similar results, but also some
> > small differences:
> Thanks for verifying. Just out of interest, which OpenSSH version do
> you have?
openssh-6.6p1 (on openSUSE Tumbleweed, the rolling release)
> > - I additionally need capability sys_ptrace,
> > - I don't need w access to /var/log/btmp (but nevertheless it makes
> > sense to allow it)
>
> These might or might not be dependant on the OpenSSH version.
The configuration of OpenSSH and/or PAM might also be relevant.
> > + @{PROC}/cmdline r,
> > + @{PROC}/1/environ r,
>
> While I also get denials for these two on my Stretch VM, I did not add
> them in my initial version, as ssh seemed to work fine without and I
> really see no reason why the kernel commandline or the environment of
> the init process should matter to the ssh daemon.
Interesting point, but then I'd at least add deny rules for them to
silence the logging.
I'll mention this when sending the path upstream.
> > Can you please test with this patch? (In theory the added owner
> > restrictions could cause denials.)
>
> Yes, seems to work fine for me.
:-)
> > I'll submit the patch upstream as soon as soon as you report back
> > ;-)
>
> Cool. Thanks!
Patch sent for review upstream. The review might need a while thanks to
some[tm] [1] pending patches ;-)
Regards,
Christian Boltz
[1] there are currently 23 of my patches waiting for review, with a
total of 1597 added and 374 deleted lines ;-) (mostly for the aa-*
tools - the biggest part of the pending patches is about adding
support for dbus rules/events to aa-logprof and other aa-* tools)
--
... you start off with a typical message,
let's say a 2.5MB Word document containing
three lines of text and a macro virus ...
[Peter Gutmann]
Bug#809649: [pkg-apparmor] Bug#809649: Bug#809649: ssh login not possible when setting usr.sbin.sshd to enforced
Hello, Am Samstag, 2. Januar 2016 schrieb Evgeni Golov: > On Sat, Jan 02, 2016 at 03:50:00PM +0100, Christian Boltz wrote: > > Patch sent for review upstream. The review might need a while thanks > > to some[tm] [1] pending patches ;-) > > Cool, can you drop me the link to the review? Did not find it on > lp:apparmor. We do the reviews old-style - by sending patches to the mailinglist ;-) My mail with the patch is https://lists.ubuntu.com/archives/apparmor/2016-January/009059.html If someone replies, the answer should be linked from there. Regards, Christian Boltz -- > [lost password] Not that i know much of encrypted FS's, but id say you > are pretty lost by then. Unless you can brutecrack the encryption with > some forensics software... Start looking for post-it notes near the console [> Antun Balaz and Tom Knight in suse-security]
Bug#805145: [pkg-apparmor] Bug#805145: /usr/sbin/aa-status: aa-status --enabled hangs on upgrade until kill
Hello, the crash log contains a very interesting detail - you killed aa-status while it worked on the profile /usr/bin/python2.7//null-5ec//null-5ed//null-5...5ef//null-667//null-668//null-574fe (the line was shortened when python created the crash log, there were probably more null-* nesting levels) Those null-* profiles are used in complain mode to track exec events. In your case, there must have been *lots of* exec events, which leads to *lots of* those null-* profiles, nested as deep as the exec chain goes. Please provide the output of wc -l /sys/kernel/security/apparmor/profiles time aa-status # be patient, please ;-) I'm quite sure aa-status is _not_ in an endless loop - it's "just" busy with reading a very long list of profiles. That said - we are probably wasting CPU cycles if you only check for --enabled. That's not really noticable with 50 or 100 profiles loaded, but with > 1000 profiles (in your case mostly null-*) it might take some time. I opened https://bugs.launchpad.net/apparmor/+bug/1516400 for that. BTW: Do you really have a profile for /usr/bin/python2.7? That's probably a bad idea ;-) and I seriously recommend to delete and unload it (unless you have a _very good_ reason for what you are doing). The usual recommendation is to create a profile for the python scripts, and then have an ix (inherit) rule for the python interpreter. (This also means you have to run those scripts using "./myscript.py", not "python myscript.py".) Regards, Christian Boltz -- So we have unequivocal proof that I'm more dangerous to my own machine than any of the updates we've rolled out to Tumbleweed in the last 14 months. [Richard Brown in opensuse-factory]
Bug#742829: [pkg-apparmor] Bug#742829: Chromium browser profile not adapted to Debian packaging
Hello,
Am Montag, 19. Oktober 2015 schrieb Daniel Richard G.:
> I've never expected that we could get everyone to agree on a common
> set of paths, any more than we can get everyone to agree to drive on
> the same side of the road. But at least we can harmonize things
> between Debian and Ubuntu---there's little good reason for *that*
> inconsistency---
> and retool the Chromium profile to make it easy to deal with typical
> path variations like openSUSE's.
I know that the lib vs. lib64 difference will stay, but that doesn't
mean that we should also keep other differences "because it's already
different". Better have one difference than two ;-)
That's why I vote for using "chromium" and not "chromium-browser" ;-)
We can easily use /usr/lib{,64}/ in the profile (both name and content)
without breaking something [1]. In theory, the profile could also use
/usr/lib{,64}/chromium{,-browser}/chromium{,-browser} - but that's where
things start to become ugly to read ;-)
Regards,
Christian Boltz
[1] Yes, that will allow the Debian chromium to access /usr/lib64/ - but
since that directory doesn't exist, it won't hurt.
BTW: The profiles in the upstream AppArmor tarball and several
abstractions already use /usr/lib{,64} a lot.
--
Opensuse-Factory is mainly for systemd infights and KDE3 legacy
maintainence questions nowadays. I guess you chose the right list ;-)
[Ralf Lang in opensuse-programming]
Bug#742829: Chromium browser profile not adapted to Debian packaging
Hello,
the aliases are a nice workaround, and the tunable might really solve
the problem, but the better solution is: get rid of the problem ;-)
I'd propose to change the packages so that all distributions use the
same path. That would also mean we don't need funny hacks to adjust the
profile ;-)
Just in case you can't decide which path to use - openSUSE uses
/usr/lib64/chromium/chromium [1] and it would be nice if we can also use
the profile ;-)
Regards,
Christian Boltz
[1] that's the x86_64 path - for i586, it's /usr/lib/chromium
(that translates to /usr/lib{,64}/chromium in the profile)
--
Real programmers use chmod +x /dev/random and cross their fingers
-- Comment found in a vi/emacs flamewar on slashdot.
Bug#800132: [pkg-apparmor] Bug#800132: libapparmor-dev: arch-dependent file in "Multi-Arch: same" package
Hello, Am Sonntag, 27. September 2015 schrieb Jakub Wilk: > libapparmor-dev is marked as "Multi-Arch: same", but the following > file is architecture-dependent: > > /usr/share/man/man2/aa_getcon.2.gz > > An example diff between i386 and amd64 (after ungzipping) is attached. The aa_getcon manpage is NOT arch-dependent - the difference is just a timestamp/date. pod2man includes the last modification date of the pod file in the generated manpage. Thanks to the libapparmor-mention-dbus-method-in-getcon-man.patch, aa_getcon.pod gets a new timestamp on build (when applying the patch). The easiest solution is to submit the patch upstream, so that Debian doesn't have anything that touches the aa_getcon.pod timestamp ;-) Regards, Christian Boltz -- jjohansen: we can just label it "the can't be more broken than 2.8.3 release" ;-) cboltz: I'm disappointed in your inability to believe that I can't screw things up further. [from #apparmor]
Bug#796374: [pkg-apparmor] Bug#796374: Add AppArmor profile
Hello,
Am Samstag, 29. August 2015 schrieb intrigeri:
Nicolas Braud-Santoni wrote (21 Aug 2015 15:24:44 GMT) :
* Was this tested on current sid with systemd as pid 1? (that's
a must)
* Was this tested on Ubuntu? (nice to have, not a must)
The profile works on openSUSE, so I'd guess it should work everywhere
;-)
Note that haveged.service has DefaultDependencies=No (at least on
openSUSE), so you might need to add After=apparmor.service to ensure the
profile gets loaded first.
+/usr/sbin/haveged {
+ #include abstractions/base
+ #include local/usr.sbin.haveged
Please move the local line to the end of the profile, for
consistency with how all other profiles do it
Good idea, even if it's only cosmetics.
(also, I suspect this
allows overriding some default settings).
The ordering of rules is not relevant. The only thing that overrides
everything are deny rules.
Otherwise, sounds great! I don't remember if you've already sent this
to the AppArmor upstream mailing-list for review. Did you?
Yes, please do that ;-)
Regards,
Christian Boltz
--
Ansonsten: Ich sage nur Diwasserstoffmonoxid.
Ja, ein äußerst schädliches Zeugs, vor allem wenn es in
guten Malt gerät. [A. Schreiber und R. Döblitz]
Bug#796374: [pkg-apparmor] Bug#796374: Add AppArmor profile
Hello, Am Sonntag, 30. August 2015 schrieb intrigeri: Christian Boltz wrote (30 Aug 2015 14:38:39 GMT) : Note that haveged.service has DefaultDependencies=No (at least on openSUSE), That's the case neither on Debian, nor in any of the example service files shipped in the 1.9.1 upstream tarball. If there's a good reason to add this in OpenSuSE, perhaps it could be upstream'ed? Any pointer to the justification for this change? (There's at least one that I can think of, but if someone already wrote it down somewhere, I'm all ears.) The package changelog refers to boo#892096 - FIPS: dm_crypt hangs when mounting a crypt-file -- haveged starts too late (unfortunately non- public, but the title is useful already). For some (historic?) reason, the openSUSE package contains its own service file: https://build.opensuse.org/package/view_file/security/haveged/haveged.service?expand=1 I just requested to push the changes upstream: https://bugzilla.opensuse.org/show_bug.cgi?id=943724 Gruß Christian Boltz -- You only read the second paragraph, didn't you? Why do you write emails where one has to read the stuff between the first and the last word? [ Stephan Kulow and Dirk Mueller in opensuse-packaging]
Bug#793545: [pkg-apparmor] Bug#793545: Apparmor aa-genprof not working in jessie
Hello, Am Freitag, 24. Juli 2015 schrieb Thomas d'Otreppe: and basically, the solution is to edit the value of RE_LOG_v2_6_syslog (in class ReadLog) in /usr/lib/python3/dist-packages/apparmor/logparser.py and add (audit:\s+)? right before 'type' in the regular expression. I have a patch pending upstream that adds support for even more log formats that were ignored, and also adds tests to ensure all log formats in our collection of log sniplets work. Therefore I'd recommend to wait until AppArmor 2.9.3 gets released (which should happen in the next weeks) and then update Jessie to AppArmor 2.9.3. This means you'll get lots of bugfixes that were done since AppArmor 2.9.0 for free ;-) BTW: I'll also do a maintenance update to 2.9.3 for openSUSE ;-) Regards, Christian Boltz -- Was ist ein umbrella bug? Eine Regenschirm-Wanze ;-) [ Al Bogner und Andreas Winkelmann in suse-linux] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782700: [pkg-apparmor] Bug#782700: Please drop $remote_fs init.d dependency to allow running early
Hello, Am Donnerstag, 16. April 2015 schrieb Michael Biebl: Or maybe better: provide a native .service file, hook that up in sysinit.target and add Wants=network-pre.target Before=network-pre.target to apparmor.service. See man systemd.special FYI: I received a service file for openSUSE some weeks ago from a contributor. Basically it's just a wrapper around the initscript (so probably not the final solution), but it's a good start nevertheless ;-) [Unit] Description=Load AppArmor profiles DefaultDependencies=no Before=sysinit.target After=systemd-journald-audit.socket ConditionSecurity=apparmor [Service] Type=oneshot ExecStart=/etc/init.d/boot.apparmor start ExecReload=/etc/init.d/boot.apparmor reload ExecStop=/etc/init.d/boot.apparmor stop RemainAfterExit=yes [Install] WantedBy=multi-user.target Also let me warn you that systemd comes with some problems for AppArmor: https://bugzilla.opensuse.org/show_bug.cgi?id=853019 Basically systemd maps systemctl restart apparmor to stop, then start, which means the confinement gets removed from running processes. Regards, Christian Boltz -- Whatever, but the purpose of software is to help users, not the other way round. No, developers are not to be considered users :-p [Carlos E. R. in opensuse-factory] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670305: probably a duplicate ;-)
Hello, the problem with kern.log / syslog sounds like a duplicate of bug 771400 and https://bugs.launchpad.net/apparmor/+bug/1399027 This was fixed in libapparmor in the 2.9.1 release, however an additional patch for the python tools was commited later. This means the second half of the fix will be included in 2.9.2. Regards, Christian Boltz -- This paragraph should be next to the paragraph about modelines, not here [SLE 12 manual draft, in the section about apparmor.vim] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771400: apparmor-utils: aa-logprof/aa-genprof not updating policy
Hello, Reading log entries from /var/log/syslog. https://bugs.launchpad.net/apparmor/+bug/1399027 Can you please install and start auditd and try again? (aa-genprof should automatically switch to reading /var/log/audit/audit.log if it exists) If this works, this bug is a duplicate of upstream https://bugs.launchpad.net/apparmor/+bug/1399027 If I'm right, please send some _unmodified_ log lines from /var/log/syslog. We need some samples so that we can fix the support for the syslog log format. Regards, Christian Boltz -- jdstrand jjohansen: curious-- is there a reason why child profiles can't contain a '-' in their name? jjohansen jdstrand: yes, because its not in the regex :P jdstrand jjohansen: is there a reason why '-' is not in the child profile regex? ;P [from #apparmor] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715640: [Mayhem] Bug report on apparmor: apparmor_parser crashes with exit status 139
Hello, I just tried to reproduce this bug with AppArmor 2.9 (on openSUSE ;-) The parser doesn't crash anymore: ./crash.sh Warning from stdin (line 1): /sbin/apparmor_parser: cannot use or update cache, disable, or force-complain via stdin AppArmor parser error, in stdin line 1: syntax error, unexpected $end, expecting TOK_OPEN Regards, Christian Boltz -- [Subject: Re: hpdarm bei Systemstart] Äh, sorry, es geht natürlich um hdparm, nicht um die Gedärme eines hp:-) [Heinrich Eisterer in suse-linux] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#389019: css file not correctly put in place on modlogan run
The CSS file should only be symlinked if it does not exist yet. If modlogan.css already exists (as symlink or plain file), it should not be overwritten. There might be reasons to have a different CSS file for some domains / outputdirs. -- Christian Boltz www.cboltz.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
