Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754204Ab1ECRPP (ORCPT ); Tue, 3 May 2011 13:15:15 -0400 Received: from 236.121.91-79.rev.gaoland.net ([79.91.121.236]:58714 "EHLO mx.synack.fr" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753988Ab1ECRPN (ORCPT ); Tue, 3 May 2011 13:15:13 -0400 From: Samir Bellabes To: Casey Schaufler Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, jamal , Patrick McHardy , Evgeniy Polyakov , Grzegorz Nosek Subject: Re: [RFC v3 00/10] snet: Security for NETwork syscalls References: <1304432663-1575-1-git-send-email-sam@synack.fr> <4DC0330C.60208@schaufler-ca.com> Date: Tue, 03 May 2011 19:15:10 +0200 In-Reply-To: <4DC0330C.60208@schaufler-ca.com> (Casey Schaufler's message of "Tue, 03 May 2011 09:53:32 -0700") Message-ID: <874o5b3dup.fsf@synack.fr> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2510 Lines: 56 Casey Schaufler 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/