From: Samir Bellabes <sam@synack.fr>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, jamal <hadi@cyberus.ca>,
Patrick McHardy <kaber@trash.net>,
Evgeniy Polyakov <zbr@ioremap.net>,
Grzegorz Nosek <root@localdomain.pl>
Subject: Re: [RFC v3 00/10] snet: Security for NETwork syscalls
Date: Tue, 03 May 2011 19:15:10 +0200 [thread overview]
Message-ID: <874o5b3dup.fsf@synack.fr> (raw)
In-Reply-To: <4DC0330C.60208@schaufler-ca.com> (Casey Schaufler's message of "Tue, 03 May 2011 09:53:32 -0700")
Casey Schaufler <casey@schaufler-ca.com> writes:
> On 5/3/2011 7:24 AM, Samir Bellabes wrote:
>> Hello lsm and netdev people,
>> This set of patches is the version 3 of snet, which I would like to submit as a
>> RFC.
>>
>> snet is a linux security module. It provides a mecanism defering syscall
>> security hooks and decision (verdict) to userspace.
>
> As you have submitted this as a Request For Comments I will make one.
>
> I first saw this approach in 1987, on Unix, from a company called
> SecureWare (long completely assimilated into HP). The potential for
> deadlock, where the system prevents the decision making application
> from accessing the information it needs to grant itself access is
> great. The performance impact of making security checks in user
> space is appalling. The exposure for attack, especially regarding
> denial of service, is enormous. I do not recommend this approach.
>
> There are cases where user space access control assistance could
> be appropriate, in particular controls based on the data involved.
> Even those controls must be very carefully crafted to avoid
> impacting the correct function of the system in the unhappily
> likely event of the access control enforcing applications being
> unavailable or incapable of keeping up with demand.
>
As everything may be exposed to denial of service attack..
I have some thoughts. snet is not a tool for securing the kernel code,
there is only one way to do so, it's to fix bug and to add code feature
to protect memory (cf grsecurity). snet is a tool to manage the
behaviour of users and applications, regarding network connections.
the risk of deadlock is uneffective, as every sleeps occurs in process
context, so application can sleep without trouble.
there are 2 ways to go out of sleep :
- receiving the verdict
- timeouting
so deadlock are more "latency".
You win a admin tool, you loose some latency. I'm ok with that, as this
feature as its own public.
and of course, I'm not pretending to add a new idea. I'm sure some
mecanism like this already exist before 1987. I'm just the man who put
the code in order to be discuss on the lists, which was never been done
so far.
there are some request from public distro:
http://brainstorm.ubuntu.com/idea/23333/
prev parent reply other threads:[~2011-05-03 17:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 14:24 [RFC v3 00/10] snet: Security for NETwork syscalls Samir Bellabes
2011-05-03 14:24 ` [RFC v3 01/10] lsm: add security_socket_closed() Samir Bellabes
2011-05-03 15:29 ` Tetsuo Handa
2011-05-03 15:41 ` Samir Bellabes
2011-05-03 14:24 ` [RFC v3 02/10] Revert "lsm: Remove the socket_post_accept() hook" Samir Bellabes
2011-05-03 22:02 ` Paul Moore
2011-05-04 2:28 ` Tetsuo Handa
2011-05-04 8:50 ` Samir Bellabes
2011-05-05 14:11 ` Paul Moore
2011-05-05 21:43 ` Tetsuo Handa
2011-05-06 9:25 ` Samir Bellabes
2011-05-06 17:27 ` Paul Moore
2011-05-03 14:24 ` [RFC v3 03/10] snet: introduce snet_core Samir Bellabes
2011-05-03 14:24 ` [RFC v3 04/10] snet: introduce snet_event Samir Bellabes
2011-05-03 14:24 ` [RFC v3 05/10] snet: introduce snet_hooks Samir Bellabes
2011-05-03 14:24 ` [RFC v3 06/10] snet: introduce snet_netlink Samir Bellabes
2011-05-03 14:24 ` [RFC v3 07/10] snet: introduce snet_verdict Samir Bellabes
2011-05-03 14:24 ` [RFC v3 08/10] snet: introduce snet_ticket Samir Bellabes
2011-05-03 14:24 ` [RFC v3 09/10] snet: introduce snet_utils Samir Bellabes
2011-05-03 14:24 ` [RFC v3 10/10] snet: introduce security/snet, Makefile and Kconfig changes Samir Bellabes
2011-05-03 16:53 ` [RFC v3 00/10] snet: Security for NETwork syscalls Casey Schaufler
2011-05-03 17:15 ` Samir Bellabes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874o5b3dup.fsf@synack.fr \
--to=sam@synack.fr \
--cc=casey@schaufler-ca.com \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=root@localdomain.pl \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).