Bug#712451: apparmor not support network rule

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug#712451: apparmor not support network rule

John Wong
Package: apparmor
Version: 2.7.103-4
Severity: normal

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 ***


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=zh_HK.utf8, LC_CTYPE=zh_HK.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.50
ii  dpkg                   1.16.10
ii  initramfs-tools        0.112
ii  libc6                  2.17-5
ii  lsb-base               4.1+Debian12
ii  python                 2.7.5-2

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-docs      2.7.103-4
ii  apparmor-profiles  2.7.103-4
ii  apparmor-utils     2.7.103-4

-- Configuration Files:
/etc/apparmor.d/abstractions/base changed [not included]
/etc/apparmor.d/abstractions/ibus changed [not included]
/etc/apparmor.d/abstractions/private-files-strict changed [not included]
/etc/apparmor.d/abstractions/ubuntu-browsers changed [not included]
/etc/apparmor.d/abstractions/ubuntu-browsers.d/plugins-common changed [not included]
/etc/apparmor.d/abstractions/ubuntu-browsers.d/ubuntu-integration changed [not included]
/etc/apparmor.d/tunables/home changed [not included]

-- debconf information excluded


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#712451: apparmor not support network rule

intrigeri-4
Control: severity -1 wishlist
Control: retitle -1 Please support AppArmor network rules

Hi,

johnw wrote (16 Jun 2013 07:53:11 GMT) :
>    * 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?

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.

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

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

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#712451: apparmor not support network rule

John Wong
On 2013年06月16日 星期日 04:30 下午, intrigeri wrote:
> 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.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#712451: apparmor not support network rule

intrigeri-4
Hi,

johnw wrote (16 Jun 2013 12:31:29 GMT) :
> On 2013年06月16日 星期日 04:30 下午, intrigeri wrote:
>> 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?

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.

> If you never did it, I will open the new bug report to
> linux-image(should I do it?)

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

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#712451: apparmor not support network rule

intrigeri-4
Control: tag -1 upstream

intrigeri wrote (16 Jun 2013 13:26:27 GMT) :
> The action that should be taken now belongs upstream.

Flagging as such: IMO it is not Debian's responsibility to fix the
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.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
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

:)

Reply | Threaded
Open this post in threaded view
|

Bug#712451: [pkg-apparmor] Bug#712451: Please support AppArmor network rules

Vincas Dargis
Woohoo!

What's next left, DBus?

On 4/20/18 11:45 AM, intrigeri wrote:
> 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
>
> :)

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
In reply to this post by intrigeri-4
intrigeri:
> 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

… 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?

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Vincas Dargis
On Wed, 13 Jun 2018 19:44:58 +0200 intrigeri <[hidden email]> wrote:
> 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.

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Vincas Dargis
In reply to this post by intrigeri-4
On Wed, 13 Jun 2018 19:44:58 +0200 intrigeri <[hidden email]> wrote:
> 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.

Got ideas how could I install 4.17 on Stretch?

```
$ 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..?

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
In reply to this post by Vincas Dargis
Vincas Dargis:
> On Wed, 13 Jun 2018 19:44:58 +0200 intrigeri <[hidden email]> wrote:
>> 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!

Amazing! \o/

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

Nice :)

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
In reply to this post by Vincas Dargis
Vincas Dargis:
> linux-compiler-gcc-7-x86 needs gcc-7 that is not available?

For Tails we work this around with equivs:
https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/12-kernel-modules-build-environment

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Vincas Dargis
On Sun, 17 Jun 2018 16:36:39 +0200 intrigeri <[hidden email]> wrote:
> Vincas Dargis:
> > linux-compiler-gcc-7-x86 needs gcc-7 that is not available?
>
> For Tails we work this around with equivs:
> 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...

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
Hi Vincas,

Vincas Dargis:
> 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.

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?

> 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...

Absolutely.

Cheers,
--
intrigeri

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Vincas Dargis
On 7/22/18 3:48 PM, intrigeri wrote:
> Hi Vincas,
>
> Vincas Dargis:
>> 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.
>
> Great.
>
> Both on Stretch, right?

Yes.

>
> 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?

I have feature-set commented out.

>
>> 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...
>
> Absolutely.

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

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

intrigeri-4
Hi,

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

Vincas Dargis:
> On 7/22/18 3:48 PM, intrigeri wrote:
>> Vincas Dargis:
>>> 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.
>>
>> Great.
>>
>> Both on Stretch, right?

> Yes.

>> 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?

> I have feature-set commented out.

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?

>>> 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...
>>
>> Absolutely.

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

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

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

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

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.

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Vincas Dargis
On Tue, 24 Jul 2018 18:38:49 +0800 intrigeri <[hidden email]> wrote:
> John answered my question on IRC:
>
> - "you can't yet. You will need an apparmor 3.0 beta which keeps
>   getting delayed"


Aawww.. Anyway, good to know :) .

Reply | Threaded
Open this post in threaded view
|

Bug#712451: Please support AppArmor network rules

Paolo Greppi
In reply to this post by John Wong
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

Reply | Threaded
Open this post in threaded view
|

Bug#712451: [pkg-apparmor] Bug#712451: Please support AppArmor network rules

intrigeri-4
Paolo Greppi:
> Should this be documented in /usr/share/doc/apparmor/README.Debian ?

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

Cheers,
--
intrigeri

12