Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   reload apparmor rule.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   apparmor_parser -r rule

   * What was the outcome of this action?
   it show the waring message: "network rules not enforced"

   * What outcome did you expect instead?
   enforced network rules, without warning/error message.

   I think it is because debian kernel (my: linux-image-3.9-1-amd64/3.9.6-1) does not fully support apparmor, is it?
   is it ture, can you point me, where can I download the patches set,
   make the kernel support apparmor (at least support network rule).

   Do you use apparmor on debian with network rule? if yes,
   any suggestion, how to make the kernel support apparmor network rule
   on debian?

   If it is not the kernel problem, can you tell me how to make apparmor
   support network rule?

   Thank you.


*** End of the template - remove these lines ***

Hi,

johnw wrote (16 Jun 2013 07:53:11 GMT) :

It's because the AppArmor patches about network mediation were not
merged upstream yet.

FYI Jessie's Debian kernel is not likely to ship out-of-tree AppArmor
patches, so I'm not reassigning to the linux package, but keeping it
under the apparmor package umbrella for the time being.

You may want to nag AppArmor upstream so that they have the network
mediation code merged into mainline Linux :)

Cheers,

Ok, I am not complain, but did you talk to debian kernel team/developer
this issue?
again, I am not complain, I just want know, what (apparmor/kernel)
developer think.
If you never did it, I will open the new bug report to
linux-image(should I do it?)
thank you.

Hi,

johnw wrote (16 Jun 2013 12:31:29 GMT) :

We talked during the Wheezy dev cycle, and they applied minimal
AppArmor patches at this time, but that was on the grounds that these
patches were well on their way to the mainline kernel, and therefore
probably would not be needed for Jessie. So I don't think it's useful
to ask them any such thing right now. The action that should be taken
now belongs upstream.

I don't think this would be a sensible move.
Please take the matter upstream instead, thanks :)

Cheers,

intrigeri wrote (16 Jun 2013 13:26:27 GMT) :
situation. AppArmor userspace has been depending on out-of-tree kernel
patches since at least Linux 2.6.36, and there is little we can do
about it.

Linux v4.17-rc1 now supports basic socket mediation, which will allow
us to close this bug report:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56974a6fcfef69ee0825bd66ed13e92070ac5224

:)

Woohoo!

What's next left, DBus?

intrigeri:

… which made it into v4.17 final :)

We could start testing our policy locally with socket
mediation enabled. To do so:

 - run Linux from Debian experimental (it currently has 4.17~rc7-1~exp1)
 - disable feature-set pinning or update the feature-set to enable
   these new features

Also, it would be nice to test Linux 4.17 with the feature-sets we
ship in Stretch and testing/sid, in order to catch any bug like
#883703 ASAP.

I'll be very busy until DebCamp so it's unlikely I do much on this
front until then (best case I'll press the right buttons to enable
this on my own system once 4.17 is in sid, but I won't have time to
test software I don't use myself).

Anyone excited?

I am!

Currently I see no immediate breakages with Linux 4.17 and AppArmor 2.13
so far.

```
$ sudo apt install -t experimental linux-headers-4.17.0-rc7-amd64
linux-image-4.17.0-rc7-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'linux-image-4.17.0-rc7-amd64-unsigned' instead of
'linux-image-4.17.0-rc7-amd64'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  linux-headers-4.17.0-rc7-amd64 : Depends: linux-compiler-gcc-7-x86 (>=
4.14.17-1~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages
```

linux-compiler-gcc-7-x86 needs gcc-7 that is not available?

```
  linux-compiler-gcc-7-x86 : Depends: gcc-7 (>= 7.2.0-20~) but it is not
installable
```

gcc-7 is only in Testing. Will 4.17 be available as Stretch backport at
all..?

Vincas Dargis:

Amazing! \o/

Nice :)

Vincas Dargis:
https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/12-kernel-modules-build-environment

I've managed to install 4.17.0-rc3 and 4.18.0-rc4 with equivs hack, and I did not see any immediate
problems with some lightweight testing.

Though it would be really nice to have some sort of integration test suite for apparmor-confined
packages to do some serious testing before releasing upgrades...

Hi Vincas,

Vincas Dargis:

Great.

Both on Stretch, right?

Did you disable feature-set pinning entirely or update the feature-set
to enable the new features? If the latter, can you please share the
exact feature-set you've used?

Absolutely.

Cheers,

Yes.

I have feature-set commented out.

Does Debian packages has infrastructure for integration tests that maintainer could run after building?

Hi,

(John, one question for you below, please search for your name :)

Vincas Dargis:

OK!

I'm now running 4.17 from sid without feature set pinning and did not
notice any breakage either.

*But* I don't think that just upgrading to 4.17 actually gives me
network socket mediation. I have this in parser.conf:

  warn=rule-not-enforced
  warn=rule-downgraded

… and when compiling policy, I see "network rules not enforced" all
over the place.

Then I've read somewhere that network socket mediation might need
newer userspace (I'm running 2.13 from Debian experimental).

John, could you please tell me how I can benefit from the network
socket mediation feature that was merged into Linux 4.17?

Yes: autopkgtest. If you're interested in working on this, please
start a dedicated thread on the team ML or on a new bug report :)

Cheers,

intrigeri:

John answered my question on IRC:

- "you can't yet. You will need an apparmor 3.0 beta which keeps
  getting delayed"
- "for various reasons, I won't let the network patches into the wild
  without the tie to the feature abi work"

So let's put this on the back burner until there's userspace available
to benefit from the new kernel feature.

Aawww.. Anyway, good to know :) .

I looked at the status of this on buster:

uname -a
Linux localhost.localdomain 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux

and the issue still can be reproduced (in the sense that telnet.netkit network access will not be blocked after enforcing the rule).

Except it is worse because this command:
sudo apparmor_parser -vr  /etc/apparmor.d/usr.bin.telnet.netkit
does not show anymore the message "network rules not enforced".

Should this be documented in /usr/share/doc/apparmor/README.Debian ?

This currently refers to: https://wiki.debian.org/AppArmor but there is no mention of this limitation in there.

Paolo

Paolo Greppi:

FWIW, this is now mentioned in the manpage that documents the policy
language: apparmor.d(5)

Cheers,

intrigeri:
mentions of features that does not work in Debian yet. Maybe such notice
should be placed in "Network Rules" section of the manual? Or in
"KNOWN BUGS"? So that newcomers will not be misguided (like me).

Okay, it's my bad that I have not checked explicitly if it works. But
IMO there is an issue with documentation if you can't understand from it
what is supposed to be working and what is not.

By the way, ping under apparmor fails with "ping: socket: Operation not
permitted", while wget or curl works pretty well under the same profile.
Don't know if it is supposed to be like it.

Heenec

Hi,

Heenec (2020-04-09):

On my sid system I see this on top of apparmor.d(5):

NAME
       apparmor.d - syntax of security profiles for AppArmor.

DESCRIPTION
       AppArmor profiles describe mandatory access rights granted to given
       programs and are fed to the AppArmor policy enforcement module using
       apparmor_parser(8). This man page describes the format of the AppArmor
       configuration files; see apparmor(7) for an overview of AppArmor.

       Some features are not supported on Debian yet:

       Network Rules
       DBus rules
       Unix socket rules

I would gladly review a MR against Vcs-Git that implements this :)

Greetings,

As AppArmor v3.0 is now released[1], is there a chance that network, dbus and
sockets will be supported in Bullseye?

[1] https://lists.ubuntu.com/archives/apparmor/2020-October/012183.html

AppArmor 3 allows use of networkv8 rules (ie, what is in the upstream
kernel) so apparmor 3 in Debian would allow for this to work.

The upstream kernel does not yet support AF_UNIX rules, so anonymous
sockets, abstract sockets and dbus won't be available. Work has picked
up to get this into the upstream kernel (perhaps 5.11).

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.

Hello,

Am Donnerstag, 7. Januar 2021, 13:22:42 CET schrieb Christian Ehrhardt:

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.

 Greetings From KNOC,

Hope my mail finds you in good health.

We the Korea National Oil corporation (KNOC) invite you to partner with us
and benefit in our 2021 Loan funding program.

(KNOC) is a Giant in maintains extensive technology, oil exploration,
development, production and financing investment project, KNOC investment
funding activity specializes in real estate and hospitality, industrial and
sustainable technologies, strategic financial investments, Starting up
Business Expansion, Commercial Real Estate purchase, Contract Execution,
Healthcare services, Agriculture, manufacturing, mining and Energy
projects.

KNOC offers 1.5% commission to brokers, who wish to work with us by
presenting viable project owners for project finance or other
opportunities.

Korea National Oil Corporation (KNOC) is acting as a lender and the fund
will be disbursed on a clear interest rate of 3.5% annually to our partners
and Entrepreneurs for their investment projects.

Contact us on the below emails for further discussion.

Thank you looking forward hearing from you soonest

Best Regards,
Lee Seungho
Loan Processor
On behalf of Mr. Su Yang Young

Hi,

Lambda Team (2023-04-18):

Right, as documented in the apparmor.d(5) manpage on Debian:

  Some features are not supported on Debian yet:

       Network Rules
       DBus rules
       Unix socket rules

This is tracked on https://bugs.debian.org/712451, which is probably
outdated, since I believe things have improved since the last update
there. As you mentioned, on Bookworm, with AppArmor 3.0 userspace, we
should have at least some support for network mediation (as in, given
a policy without any network rule, network operations will be denied).

If someone tested on Bookworm or newer, and reported back how they
tested this (ideally in a way that others can review & reproduce),
then we could:

 - update the doc accordingly
 - fix (or at least track) any remaining problem

Cheers,