User: Password:
Subscribe / Log in / New account

Draft version of TOMOYO Linux 2.3

From:  Tetsuo Handa <from-tomoyo-users-en-JPay3/>
Subject:  [tomoyo-users-en 104] Draft version of TOMOYO Linux 2.3
Date:  Mon, 21 Sep 2009 22:54:04 +0900
Archive-link:  Article, Thread


Revision 3060 is a draft for next version of TOMOYO 2.x .

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) {
  if (FD_ISSET(listener)) {
     fd = accept(listener);
  /* 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?

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds