linux-kernel - Re: [RFC v3 00/10] snet: Security for NETwork syscalls

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]

Message-ID: <874o5b3dup.fsf@synack.fr>
Date:	Tue, 03 May 2011 19:15:10 +0200
From:	Samir Bellabes <sam@...ack.fr>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, jamal <hadi@...erus.ca>,
	Patrick McHardy <kaber@...sh.net>,
	Evgeniy Polyakov <zbr@...emap.net>,
	Grzegorz Nosek <root@...aldomain.pl>
Subject: Re: [RFC v3 00/10] snet: Security for NETwork syscalls

Casey Schaufler <casey@...aufler-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/
--
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/