linux-kernel - Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

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: <200709051006.28429.paul.moore@hp.com>
Date:	Wed, 5 Sep 2007 10:06:28 -0400
From:	Paul Moore <paul.moore@...com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [TOMOYO 15/15] LSM expansion for TOMOYO Linux.

On Tuesday 04 September 2007 10:02:46 am Tetsuo Handa wrote:
> According to Patrick McHardy's posting at
> http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg00999.
>html netfilter *socket filters* cannot know final recipient process.
> Can netfilter *userspace queue mechanism* know final recipient process?

Okay, I just went back and re-read the conversation from July as well as the 
description of your current patches and I think what is basically comes down 
to is that your design makes use of userspace intervention to allow/reject 
connections and/or packets based on the application's domain.  Unfortunately 
for TOMOYO, the current LSM network hooks are placed in such a way that you 
can not block and query a userspace agent for an access control decision.

Myself and some others have suggested using the netfilter userspace queue 
mechanism[1].  However, I understand this may cause you problems when you try 
to determine the incoming packet's destination/domain.  With these 
requirements I understand why you are pushing so hard to introduce these new 
LSM hooks, but for many reasons I would really prefer to try and find a way 
to utilize the existing hooks.  I've tried to think of a way to do this over 
the past day and have not been able to arrive at a clean solution.  
Personally, I still question the wisdom of receiving a packet/connection only 
to drop/reject it later when an application tries to read it but I might be 
the only one.

Based on some of the other discussion around this patch there appears to be 
other, larger issues which you still need to sort out (language parser in the 
kernel, /proc issues, etc.).  I would recommend addressing those concerns and 
including the netdev mailing list on your next patchset as they might have 
some thoughts on your network design.

[1]http://www.netfilter.org/projects/libnetfilter_queue/index.html

-- 
paul moore
linux security @ hp
-
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/