Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tetsuo Handa <from-tomoyo-users-en-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp <at> public.gmane.org>
Subject: [tomoyo-users-en 104] Draft version of TOMOYO Linux 2.3
Newsgroups: gmane.linux.tomoyo.user.english
Date: Monday 21st September 2009 13:54:04 UTC (over 8 years ago)
Hello.

Revision 3060 is a draft for next version of TOMOYO 2.x .
http://sourceforge.jp/projects/tomoyo/svn/view/trunk/2.3.x/?root=tomoyo

It contains all features in TOMOYO 1.7.0 plus /\{dir\}/ matching support
minus DAC-before-MAC-checking
minus incoming network connection/packets restriction ("allow_network TCP
accept"/"allow_network UDP connect"/"allow_network RAW connect" keywords)
minus signal transmission restriction ("allow_signal" keyword)
minus many of capabilities ("allow_capability" keyword).

The final specification of TOMOYO 2.3 will be determined when it is acked
by
the LSM and fsdevel people. The question is how large part of this draft is
accepted for mainline kernel.



Regarding incoming network connection/packets restriction, this is
impossible
because post-accept()/recvmsg() hooks are missing.

I don't want to use pre-accept()/recvmsg() hooks.
Since there is no LSM hook for select()/poll() but there are LSM hooks for
accept()/recvmsg(), returning an error at
security_socket_accept()/security_socket_recvmsg() will lead to unwanted
results. Very simplified code is shown below.

while (1) {
  select();
  if (FD_ISSET(listener)) {
     fd = accept(listener);
     continue;
  }
  /* work with fd */
}

select()/poll() returns immediately if incoming connections/datagrams are
ready to be picked up. But pending connections/datagrams remains in the
queue
if pre-accept()/recvmsg() hook returns an error.

If the application closes the socket when accept()/recvmsg() returned
-EPERM,
MAC's decision disturbed the application's functionality.

If the application does not close the socket when accept()/recvmsg()
returned
-EPERM, subsequent select()/poll() returns immediately and
accept()/recvmsg()
also returns -EPERM immediately. This brings an ever-lasting busy loop.
MAC's decision made the application to consume 100% of CPU resource.

Oh, what was the purpose of using select()/poll()? We use select()/poll()
to
avoid CPU consumption, don't we? But MAC's decision lets the application
consume 100% of CPU resource. Who is happy?

I want to remove pending connections/datagrams from the queue before
returning
an error to the caller. Also, I want to return -ECONNABORTED for accept()
and
-EAGAIN for recvmsg() so that the error will not disturb the application's
functionality, but returning -EAGAIN seems unacceptable for mainline.

If post-accept()/recvmsg() hooks are provided with "void" type (so that the
caller does not receive an error code), we have a chance to mark the
connection dead and the datagram truncated.

Any ideas for implementing incoming network connection/packets restriction
using the caller's domain and the peer's address/port information?
 
CD: 3ms