netdev - Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Jan 2009 10:32:54 +0100 (CET)
From:	"Rob Meijer" <capibara@...all.nl>
To:	"Peter Dolding" <oiaohm@...il.com>
Cc:	rmeijer@...all.nl, "Casey Schaufler" <casey@...aufler-ca.com>,
	"Samir Bellabes" <sam@...ack.fr>, imipak@...oo.com,
	"linux-security-module" <linux-security-module@...r.kernel.org>,
	"Stephan Peijnik" <stephan@...jnik.at>, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal  
     firewalls"

On Wed, January 21, 2009 09:15, Peter Dolding wrote:

> Netfilter can already reject or approve out going packets from
> applications on the base of user id process id and so on.  This is
> before packets enter the Netfilter processing stack.   Cost of looking
> up if applicaiton is approved or not appoved is out weight be the cost
> of rejected packets going trough netfilter.
>
> Sorry netfilter is already sorting out how sockets can be used.   What
> you are basically talking about is two layors doing exactly the same
> thing.   Half of what tuxguardian does can be done in a iptables
> module.  Ie filtering out going traffic based on application.
>
> Please explain why expanding netfilter is not a option.   Expanding
> netfilter avoids conflicts with LSM's.
>

Agreed patches to Netfilter might get you a long way. Along the lines of
--owner-uid you may extend it with something like --owner-exe and possibly
--owner-callchainid. That could take care of:

* connection-full-protocol like TCP
* outgoing connection-less-protocol packets like UDP or ICMP

The one thing that would remain would be incoming connection-less-protocol
packets. If Netfilter could be patched in such a way that incoming packets
could be filtered based on receiving process meta, that would be a great
way to go. If not, maybe LSM would need to just mediate 'bind'.

A second issue comes with user level administration. If Netfilter would be
patched to allow a user to administrate her 'private' table, that could
get called from the system wide Netfilter rules, some MAC framework would
still be needed to make sure the user has a way to change the rules in her
private table, but her browser, pdf reader, mail client etc have not.

That is, you could define some system wide ruleset like:

System wide:
  * deny any packet from executables under '/home/*'
  * deny any packet from user 'localuser'
  * for any packet from an executable under /usr/bin/networkingtools/ jump
    to the users USERPRIVATE table.
  * deny all other trafic.

User alice USERPRIVATE:
  * allow all packets from /usr/bin/webbrowser to anything on tcp port 80.

User bob USERPRIVATE:
  * allow all packets from /usr/bin/webbrowser to the socks port of the
    socks server.

Would a solution like that be feasible?

You would want alice or bob to be able to change their USERPRIVATE table,
but you wouldn't want /usr/bin/webbrowser or any other program to do so
independently. At least for that you would need close cooperation with
for example SeLinux or AppArmor.

Further it seems that 'bind' for connection less sockets will still be
important a candidate for mediation by LSM IMHO.

Rob.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html