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: <200709042302.CDE26023.MJOOLQVFFOtHSF@I-love.SAKURA.ne.jp>
Date:	Tue, 4 Sep 2007 23:02:46 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	paul.moore@...com
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.

Hello.

Thank you for your comment.

Hmm, I can't understand why I have to perform access control at "enqueue" time.

What I want to do is
  allow process1 receive UDP packets from 10.0.0.1 port 1024
  allow process2 receive UDP packets from 10.0.0.2 port 2048
when there is no guarantee that process1 and process2 are not sharing a socket.

If there is guarantee that process1 and process2 are not sharing a socket,
I can do it using netfilter.

My case is that process1 and process2 might share a socket
but allow administrator give process1 and process2 different region of interests.

> As mentioned before that problem with enforcing access control at "dequeue" 
> time is that the system has already accepted the packet from the remote 
> host - how do you plan to deal with these unacceptable/bad packets sitting on 
> a socket, waiting to be read by a process which does not have access to them?  
Just drop unacceptable/bad packet when a process attempted to pick up a packet
that is not region of interest for the process;
with a price of being unable to pick up packets that are region of interest
for other process that are sharing that socket.
But processes that administrator gives different region of interests
seldom shares a socket, the administrator seldom pays this price.

> What about connection oriented sockets where the remote host will assume 
> everything is okay and continue blasting the machine with more, illegal 
> packets?  If you aren't going to allow the socket/application to read the 
> packet, never allow the system to accept it in the first place.
I don't plan to drop connection oriented socket's packets at skb_recv_datagram().
TOMOYO Linux drops UDP or RAW packet at skb_recv_datagram()
and disconnects TCP connection at socket_post_accept().
In both cases, no uninterested data is picked up by userland process.

Sockets deliver packets between two host's kernel space,
but have no concern about delivered packets has been picked up.
It is sender process's business to verify that
receiver process has successfully picked up packets
which sender process has sent.

> The *preferable* solution, as previously stated before by several people, is 
> to investigate other access control methods like the netfilter userspace 
> queue mechanism.  At the very least, please explain how the approaches we 
> proposed will not accomplish what you require.
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?

Regards.
-
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/