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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Sep 2008 20:43:01 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Tilman Baumann <tilman.baumann@...lax.com>
CC:	Linux-Kernel <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org
Subject: Re: SMACK netfilter smacklabel socket match

Tilman Baumann wrote:
> Hi all,
>
> i made some SMACK related patches. I hope this list is the right place 
> to post them.

Here and, probably more importantly 
linux-security-module@...r.kernel.org as that's
my primary hang out.

> The intention behind this patch is that i needed a way to (firewall) 
> match for packets originating from specific processes.
> The existing owner match did not work well enough, especially since 
> the cmd-owner part is removed.
> Then i thought about a way to tag processes and somehow match this tag 
> in the firewall.
> I recalled that SELinux can do this (SECMARK) but SELinux would have 
> been way to complex for what i want. But the idea was born, i just 
> needed something more simple.
>
> SMACK seemed to be the right way. So i made a little primitive 
> netfilter match to match against the security context of sockets.
> SMACK does CIPSO labels, but this was not what i wanted, i wanted to 
> label the socket not the packet (on the wire).
> This of course only works for packets with a local socket, but this 
> was my intention anyway.
>
> This way i can label a process and all it's sockets carry the same 
> label which i then can use to match against in the firewall.
>

Hmm. It looks as if your code will do what you're asking it to do.
Are you going to be happy with the access restrictions that will be
imposed by Smack?

> The code is pretty much based on cargo cult coding from other 
> netfilter matches, especially the owner match (which turned out to be 
> a bad reference since it is crapped with tons of compat interfaces).
>
> I have no kernel coding experience whatsoever and little C coding 
> history. So i would really like you guys to look over it a bit.
>
> Originally i intended to put this mask in the xtables_match structure.
> .hooks = (1 << NF_INET_LOCAL_OUT) | (1 << NF_INET_LOCAL_IN)
> But it turned out that i then could not longer put the rule in a chain 
> which is called by the OUTPUT chain but only in OUTPUT directly.
> I did not investigate much more since i did not really understand this 
> part. Allowing the user to add this match wherever he wants to does 
> not hurt, if there is no local socket there is no matching.
> But maybe this is something that should be changed.
>
> About the Files:
> SMACK-netfilter-socket-label-match.patch
> is a git patch for the current kernel.
>
> iptables-smacklabel.patch
> contains the iptables userspace part (applies to iptables-1.4.1.1)
>
>
> Regards
>  Tilman Baumann

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ