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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Jan 2009 01:54:00 +0100
From:	Samir Bellabes <sam@...ack.fr>
To:	imipak@...oo.com
Cc:	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"

Jonathan Day <imipak@...oo.com> writes:

> --- On Tue, 1/20/09, Stephan Peijnik <stephan@...jnik.at> wrote:

[...]

>> This means personal firewalls should not enforce system
>> security policy,
>> but rather a per-user security policy.
>> The implementations can then add caching of decisions made
>> (ie.
>> "remember this decision") and thus not ask every
>> time a call is made.
>> Also, the only protocols to be supported are IPv4 and IPv6.
>> Adding
>> support for AF_UNIX and/or AF_NETLINK doesn't make much
>> sense, as this
>> is not network-related and would only increase the amount
>> of work a
>> personal firewall implementation has to do.
>
> I agree that Unix and Netlink would not be useful, but there are other socket types that are LAN- or WAN-based, and I'd not be too quick to implement anything that precluded them being covered. (There's a difference between designing code in a way that makes extending it hard and actually implementing other network types, so only implementing IPv4 and IPv6 on a framework that could be extended by anyone deeply passionate about other protocls makes sense -- unless implementing it that way would be so much harder that it's pointless.)

Exactly, and the cost for the kernel subsystem and the userspace low
level part should only be adding the new elements for sending usefull
informations to the userspace and wait for verdict, but the cost for the
'personnal firewall' developper is higher (how this protocol is
interacting with others ? etc etc)

>> All proposed implementations of personal firewalls until
>> now have made
>> it rather clear that the decision-making logic should be
>> placed in
>> userspace, whilst only a small piece of code communicating
>> with a
>> userspace daemon should be placed in the kernel itself.
>
> Well, it has probably not been a significant factor in anyone's decision, but it occurs to me that per-process firewalling within the kernel makes the "per-process" bit much more complicated and would not work at all using any of the zerocopy or kernel bypass networking mechanisms.

we don't need this at all, as we are in process context, syscall can
sleep.
Trust me, it's strange to have it's web browser freezing waiting for a
timeout if the userspace part doesn't reply, but if it's replying, it's
transparent.

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