Fine-grained network mediation

Bug #796588 reported by Lars Noodén on 2011-06-13
This bug affects 21 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
linux (Ubuntu)

Bug Description

Binary package hint: apparmor

This is a wishlist item / feature request.

Increase the granularity of network restrictions to allow specification of which ports or ranges of ports can or can't be used by an application. This functionality is available in systrace if either the example or code would be of help:

John Johansen (jjohansen) wrote :

Yes, this ability should be coming in Oneiric, and we will hopefully have some test kernels out soon.

Changed in apparmor (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged

Two years ago something "should be coming" - is it correctly understood that this feature is indefinitely on hold?

Jamie Strandboge (jdstrand) wrote :

It is safe to say it has been on hold, however, this work is still planned and will hopefully be implemented by 14.04.

John Johansen (jjohansen) wrote :

No, it has been repeatedly delayed but progress has been made on it. The new base network patch on which this functionality will be built is in testing. Further work is still needed to achieve better granularity but work is being done

Kai Müller (kmueller-z) wrote :

can comment a little more on that, like what progress and where to find it? Can we expect to have it in future? Does it make sense to use dev package that converges with future versions of ubuntu? Just anything. If i can find it somewhere else, a link would help me a lot.

John Johansen (jjohansen) wrote :

like what progress and where to find it?
Its being developed as part of the upstream apparmor project. The socket labeling portion has landed in ubuntu saucy. This does not allow for control based on ports or addresses but is the basis for that work.

So what is done is a base socket labeling on which other functionality can be based. The next step would be basic address/port binding (server setting up an address), and then send address mediation. This may happen for ipv4 (not ipv6) with in the next month as part of a dev preview to get feedback on the mediation approach. It is unlikely this will make it into saucy.

Can we expect to have it in future?

Does it make sense to use dev package that converges with future versions of ubuntu?
yes. The apparmor project has a ppa that developments appear in once they reach a beta state.

Just anything. If i can find it somewhere else, a link would help me a lot.
the places to watch are the apparmor mailing list (its mostly a devel list but also takes general questions)
  <email address hidden>

and of course you can always watch the ppa. I wouldn't recommend using the ppa on a production system, at least not upgrading everytime its updated. There are times its stable and other times its not

Kai Müller (kmueller-z) wrote :

Thanks a lot!

Jamie Strandboge (jdstrand) wrote :

FYI, quite a bit more work was done on IPC in AppArmor, including the groundwork for fine-grained network mediation. Fine-grained network mediation will not land for 14.10, but may land in 15.04-15.10.

tags: added: aa-feature
Changed in apparmor (Ubuntu):
importance: Wishlist → Medium
summary: - Limit inet and inet6 access by source or destination port
+ Fine-grained network mediation
Changed in apparmor (Ubuntu):
importance: Medium → High
Changed in apparmor (Ubuntu):
status: Triaged → Confirmed
Changed in apparmor:
importance: Undecided → High
status: New → In Progress
Changed in linux (Ubuntu):
status: New → Triaged
Changed in apparmor (Ubuntu):
status: Confirmed → Triaged
Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: aa-kernel
Changed in apparmor:
status: In Progress → Confirmed
tags: added: kernel-net
Changed in apparmor:
status: Confirmed → In Progress
Jamie Strandboge (jdstrand) wrote :

FYI, this is a requirement for snapd, but it was deprioritized in favor of namespace stacking in support of LXD, upstreaming and other work in support of snappy (eg, gsettings mediation). A lot of work was done to support this, but the soonest it would be delivered given current priorities is 17.04.

Note, I'm only giving the current status, not setting the priority for this, but this feature is very high on the list and in the queue.

I suppose it's time for the bi-annual nudge on this.

More to the point, implementing this would give snaps the ability to add fine-grained network permissions for plugs, and this would suddenly make snaps a very attractive alternative to Docker images for server apps. I think this should be considered for priority.

John Johansen (jjohansen) wrote :

No disagreement that this is a high priority item. There is some work around fine grained mediation happening but I am unsure when it will land.

The problem is that this is not the only high priority item that needs to be addressed. Changing priority of these items can certainly be discussed again.

Fine-grained network security for snaps is going to be fantastic, but
it's also a rich area, and when networking policy stuff is done
simplistically it becomes awkward more than useful.

I'd suggest that we start now working up detailed design on the topic,
so that when we are ready to start implementing we have confidence that
the policy language is appropriate. I'm happy to participate in a
discussion on this in Salt Lake City at the next roadmap review, would
suggest the security team representatives bring a Discourse draft that's
had some review by the snapd team for discussion.


tags: added: kernel-key
John Johansen (jjohansen) wrote :

In 4.20 we landed some of the infrastructure to support this. Specifically secmark support was landed which provides the infrastructure needed for apparmor labels to interact with iptables and iptables to interact with apparmor.

This isn't something generally available for use yet as it infrastructure work necessary for full fine grained network mediation

Brad Figg (brad-figg) on 2019-07-24
tags: added: cscc
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers