On 1/7/19 2:16 AM, Jacek wrote: > Hi > > Apparmor hasn't a Netfilter firewall support module. > > Network rules is a good choice for applications that have AA-profiles, > but it does not protect unconfined processes for forbidden network > outgoing connections. > > I mean the function of the Security netfiter tables for SElinux, but the > easy way similar to xt_gradm, part of the Grsecurity project: > https://grsecurity.net/stable/grsecurity-2.2.0-iptables.patch > there is work in progress to support secmark (the same mechanism used by selinux) to apparmor. The base of this work landed in 4.20 and it is possible to play with it today but it has some limitations. Currently their is no integration with apparmor policy which means the label set with the secmark is limited to the label of the task that created the socket. This works for a lot of applications but is insufficient for others. It will also have issues when policy stacking is used in conjunction with network namespaces (lxd style containers). There are also problems with LSM stacking which is still in development. In addition integration into iptables, nftables etc will need some work. Long term the goal is to support both secmark and policy based networking rules. The policy based rules are necessary to be able to provide customized labels and also to support certain features not possible through the secmark. > Proposed solution (userspace): > NFtables (next Linux firewall): > > nft insert rule ip filter output meta apparmor aapolicy unconfined drop > nft insert rule ip filter output meta apparmor aapolicy enforce accept > nft insert rule ip filter output meta apparmor aapolicy complain log accept > > Iptables (current/old Linux firewall): > iptables -I OUTPUT ! -o lo -m apparmor --aapolicy unconfined -j DROP > iptables -A OUTPUT ! -o lo -m apparmor --aapolicy enforce -j ACCEPT > iptables -A OUTPUT ! -o lo -m apparmor --aapolicy complain -j LOG > --log-prefix "$PROFILE_NAME - complain: $APP_NAME" > iptables -A OUTPUT ! -o lo -m apparmor --aapolicy complain -j ACCEPT > > > > Example log from LSM Integrity IMA (Apparmor Variables - enforce) > > /audit: type=1800 audit(1546855115.951:3766): pid=12211 uid=0 auid=1001 ses=4 subj==/bin/kmod (enforce) op=appraise_data cause=IMA-signature-required comm="modprobe" name="/lib64/modules/4.19.13-gt5/kernel/net/sched/sch_codel.ko" dev="sdb1" ino=1334797 res=0/ > > /where:/ > > Apparmor Profile name & policy:/ //subj==/bin/kmod (enforce) / > Real aplication name: /comm="modprobe" / > > AA-variables - unconfined: > > [ 1703.396288] audit: type=1800 audit(1546855383.896:3777): pid=12347 uid=0 auid=1001 ses=4 subj==unconfined op=appraise_data cause=IMA-signature-required comm="modprobe" name="/lib64/modules/4.19.13-gt5/kernel/net/sched/sch_codel.ko" dev="sdb1" ino=1334797 res=0 > > where: > > AA-policy: subj==unconfined > > aplication name: comm="modprobe" > > AA-variables - complain: > > audit: type=1800 audit(1546855552.256:3785): pid=12402 uid=0 auid=1001 ses=4 subj==/bin/kmod (complain) op=appraise_data cause=IMA-signature-required comm="insmod" name="/lib64/modules/4.19.13-gt5/kernel/net/sched/sch_codel.ko" dev="sdb1" ino=1334797 res=0 > > where: > > AA - profile & policy: subj==/bin/kmod (complain) > > App name: comm="insmod" > > I'm not a programmer, is there any chance of adding a similar module in > Apparmor? > Currently it is not a module, its a build time configuration so that if the kernel being built supports it and if it is enabled in apparmor's config it is built in to the kernel as part of apparmor.
