[TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history. - Kernel

This is a discussion on [TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history. - Kernel ; "TOMOYO Linux" is our work in the field of security enhanced Linux. This is the repeated post of second submission of TOMOYO Linux ( http://lkml.org/lkml/2007/8/24/116 ). Unfortunately it was just before the Kernel Summit. We could not receive any suggestions ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: [TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history.

  1. [TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history.

    "TOMOYO Linux" is our work in the field of security enhanced Linux.
    This is the repeated post of second submission of TOMOYO Linux
    ( http://lkml.org/lkml/2007/8/24/116 ).

    Unfortunately it was just before the Kernel Summit.
    We could not receive any suggestions about our codes.
    Before this posting, we changed the program to use
    securityfs (Kyle's comment) and re-generated patches
    with the current git tree.


    When we posted our first proposal to LKML, TOMOYO Linux's MAC was
    limited to file access control. Now TOMOYO Linux has access control
    functionality not only for files but also for networking, signal
    transmission and namespace manipulation and we got the source code
    cleaned-up.

    Patches consist of four types.
    * [TOMOYO 01/15]: Mandatory modifications against standard kernel.
    * [TOMOYO 02-13/15]: LSM implementation of TOMOYO Linux.
    * [TOMOYO 14/15]: Optional modifications against standard kernel.
    * [TOMOYO 15/15]: Makefile and Kconfig .


    <>

    The fundamental concept of TOMOYO Linux is "tracking process
    invocation history".

    The "struct task_struct"->security member holds a pointer to the
    "process invocation history". Thus, every process (the kernel,
    /sbin/init process and any children/descendant of /sbin/init) knows
    its "process invocation history" (or ancestors). Since every process
    knows its ancestors, TOMOYO Linux can enforce access control over all
    processes.

    TOMOYO Linux splits domains using "process invocation history" and the
    process transits to a different domain whenever execution of a program
    (i.e. do_execve()) is requested. By transiting to a different domain
    whenever execution of a program is requested, each domain will have
    the minimal permissions that are essential for processes in that
    domain to do their roles.

    You don't need to define domains beforehand. TOMOYO Linux kernel will
    automatically define new domains whenever execution of a program is
    requested, and the process will automatically transit to the new
    domain. (If the process's domain is in enforcing mode, TOMOYO Linux
    kernel will not define new domains to avoid memory consumption attack.)

    TOMOYO Linux can restrict the following requests on a per-a-domain basis:

    * opening files
    * communicating via PF_INET sockets
    * sending signals

    TOMOYO Linux can also restrict the following namespace manipulation requests.

    * mounting filesystems
    * unmounting filesystems
    * using pivot_root


    <>

    The tree below shows a part of domain transitions generated using
    Debian Etch. The domain a process is in is determined based on the
    process's "process invocation history". Each domain has permissions
    (or ACL), and the behavior (or requests shown above) of a process is
    restricted by the ACL of the domain that the process is in.


    + /sbin/init
    + /etc/init.d/rc
    + /etc/init.d/apache2
    + /usr/bin/env
    + /usr/sbin/apache2ctl
    + /usr/sbin/apache2

    You can assign different access control modes (or profiles) on a
    per-a-domain basis. Thus, you can enforce access control partially or
    entirely. Also, by assigning "learning mode" to a domain, ACL that are
    requested by processes in that domain are automatically (i.e. in
    real-time) accumulated. The following ACL are an excerpt from
    /usr/sbin/apache2 domain generated using "learning mode".

    4 /etc/apache2/apache2.conf
    4 /var/www/apache2-default/index.html
    allow_create /var/run/apache2.pid
    allow_unlink /var/run/apache2.pid
    allow_network TCP bind 192.168.1.135 80
    allow_network TCP listen 192.168.1.135 80
    allow_network TCP accept 192.168.1.1 2389

    The above ACL allows Apache to do the following behavior.

    * Opening /etc/apache2/apache2.conf and
    /var/www/apache2-default/index.html for reading.
    * Creating and deleting /var/run/apache2.pid .
    * Binding to local address (IP = 192.168.1.135, port = 80).
    * Listening at local address (IP = 192.168.1.135, port = 80).
    * Accepting from remote address (IP = 192.168.1.1, port = 2389).

    You may use wildcards for pathnames, ranges for IP addresses and port
    numbers, groups of pathnames and IP addresses for flexible definition.


    <>

    TOMOYO Linux is an implementation of MAC, but you can use TOMOYO Linux
    not only for MAC, but also to analyze a system's behavior, since
    TOMOYO Linux can accumulate access requests raised by applications
    sorted by each "process invocation history".

    TOMOYO Linux and AppArmor are alike from the point of view of pathname
    based access control, but TOMOYO Linux has differences in the
    following points:

    * TOMOYO Linux can apply access control over the whole process
    (from the execution of /sbin/init at the startup procedure,
    till the power failure at the shutdown procedure).
    * TOMOYO Linux can apply access control not only over files but
    also over networking, signals, namespace manipulations.
    * TOMOYO Linux can accumulate ACL in real-time using
    "learning mode".

    * TOMOYO Linux allows the administrator to switch the access
    control mode on a per-domain and per-functionality basis.
    * TOMOYO Linux allows the administrator to judge (grant/reject)
    requests which that violated ACL manually while operating in
    "enforcing mode" without once rejecting these requests.
    * TOMOYO Linux supports conditional ACL (e.g. owner of
    process/files etc.).

    Documents about installing and experiencing TOMOYO Linux are available
    at http://tomoyo.sourceforge.jp/en/2.1.x/ . Please try TOMOYO Linux.
    Feedbacks are most welcome.


    <>

    OLS BoF material: http://sourceforge.jp/projects/tomoy...o-20070629.pdf
    Previous submissions: http://lkml.org/lkml/2007/6/13/58 , http://lkml.org/lkml/2007/6/14/55, http://lkml.org/lkml/2007/8/24/116

    Kentaro Takeda
    NTT DATA CORPORATION

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [TOMOYO 04/15](repost) Utility functions and securityfs interface for policy manipulation.

    On Tue, Oct 02, 2007 at 05:05:44PM +0900, Paul Mundt wrote:
    > On Tue, Oct 02, 2007 at 04:31:48PM +0900, Kentaro Takeda wrote:
    > > Common functions for TOMOYO Linux.
    > >
    > > TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration.
    > >

    > This seems like a bit of an abuse of sysfs.


    This is not sysfs, it is securityfs, big difference.

    > Isn't this precisely what configfs is for?


    Possibly, but you can do the same thing in securityfs if needed.

    thanks,

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.

    On Tue, 2 Oct 2007, Kentaro Takeda wrote:


    > --- linux-2.6.orig/net/core/datagram.c 2007-10-02 11:11:51.000000000 +0900
    > +++ linux-2.6/net/core/datagram.c 2007-10-02 11:26:23.000000000 +0900
    > @@ -55,6 +55,7 @@
    > #include
    > #include
    > #include
    > +#include
    >
    > /*
    > * Is a socket 'connection oriented' ?
    > @@ -178,6 +179,27 @@ struct sk_buff *skb_recv_datagram(struct
    > } else
    > skb = skb_dequeue(&sk->sk_receive_queue);
    >
    > + error = security_post_recv_datagram(sk, skb, flags);
    > + if (error) {
    > + unsigned long cpu_flags;
    > +
    > + if (!(flags & MSG_PEEK))
    > + goto no_peek;
    > +
    > + spin_lock_irqsave(&sk->sk_receive_queue.lock,
    > + cpu_flags);
    > + if (skb == skb_peek(&sk->sk_receive_queue)) {
    > + __skb_unlink(skb,
    > + &sk->sk_receive_queue);
    > + atomic_dec(&skb->users);
    > + }
    > + spin_unlock_irqrestore(&sk->sk_receive_queue.lock,
    > + cpu_flags);
    > +no_peek:
    > + skb_free_datagram(sk, skb);
    > + goto no_packet;
    > + }
    > +
    > if (skb)
    > return skb;


    I'm guessing you need this to determine the receiving process, rather than
    the socket (which is available via security_sock_rcv_skb()).

    If so, is this to interactively determine from the user or admin whether
    the packet should be accepted/denied for the receiving process?


    - James
    --
    James Morris

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    James Morris writes:
    >
    > All linked lists (at least, new ones) must use the standard kernel list
    > API.


    Really? Why? That rule is new to me.

    Would also seem very limiting especially since the standard kernel lists
    do not allow to express important patterns (like single linked lists)

    I don't think that is a requirement.

    -Andi
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.

    Hello.

    Thank you for your comment.

    James Morris wrote:
    > I'm guessing you need this to determine the receiving process, rather than
    > the socket (which is available via security_sock_rcv_skb()).

    Use of security_sock_rcv_skb() was discussed at http://lkml.org/lkml/2007/8/28/74 ,
    and answer is at http://lkml.org/lkml/2007/10/2/56 .

    > If so, is this to interactively determine from the user or admin whether
    > the packet should be accepted/denied for the receiving process?

    Yes, it is to determine whether the packet should be accepted/denied
    based on the receiving process (like what anti-virus software's firewall does).

    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [TOMOYO 03/15](repost) Memory and pathname management functions.

    On Tue, 2 Oct 2007, Kentaro Takeda wrote:

    > +/**
    > + * tmy_alloc - allocate memory for temporary purpose.
    > + * @size: requested size in bytes.
    > + *
    > + * Returns '\0'-initialized memory region on success.
    > + * Returns NULL on failure.
    > + *
    > + * This function allocates memory for keeping ACL entries.
    > + * The caller has to call tmy_free() the returned pointer
    > + * when memory is no longer needed.
    > + */


    Would you please explain why you need another level of memory allocation?

    What does it do apart from let you check for memory leaks?

    - James
    --
    James Morris

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [TOMOYO 03/15](repost) Memory and pathname management functions.

    Hello.

    James Morris wrote:
    > Would you please explain why you need another level of memory allocation?
    >
    > What does it do apart from let you check for memory leaks?


    Difference between tmy_alloc() and kmalloc() are

    tmy_alloc() allows administrator know "how much memory is used by TOMOYO Linux modules"
    via /sys/kernel/security/tomoyo/meminfo interface.
    This feature was requested by TOMOYO Linux users.
    /proc/slabinfo can show how much memory is used by all modules,
    but it cannot show how much memory is used by TOMOYO Linux modules.

    tmy_alloc() can indicate memory-leaking bug and can avoid double-kfree() bug
    by keeping the pointer returned by kmalloc() in a local "cache_list" list.

    tmy_alloc() also keeps the size of memory allocated by kmalloc() in "cache_list" list
    so that administrator can know "how much memory is used by TOMOYO Linux modules".
    Calling ksize() after kmalloc() in tmy_alloc() and
    calling ksize() before kfree() in tmy_free() might be better
    if double-kfree-checks and memory-leaking-checks (i.e. "tmy_cachep") are unneeded.

    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    Hello.

    YOSHIFUJI Hideaki wrote:
    > Introducing your own list is not good.
    > Please use hlist or introduce new "slist".


    James Morris wrote:
    > You're introducing a custom API, which is open-coded repeatedly throughout
    > your module.
    >
    > All linked lists (at least, new ones) must use the standard kernel list
    > API.


    It seems that standard kernel list API does not have singly-linked list manipulation.
    I'm considering the following list manipulation API.

    --- Start of code ---
    #include
    #include

    static inline void prefetch(const void *x) {;}
    #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
    #define container_of(ptr, type, member) ({ const typeof( ((type *)0)->member ) *__mptr = (ptr); (type *)( (char *)__mptr - offsetof(type,member) );})

    /*
    * nphlist -- hlist with no pointer to previous
    */
    struct nphlist_node {
    struct nphlist_node *next;
    };
    struct nphlist_head {
    struct nphlist_node *first;
    };

    #define NPHLIST_HEAD_INIT { .first = NULL }
    #define NPHLIST_HEAD(name) struct nphlist_head name = NPHLIST_HEAD_INIT
    #define INIT_NPHLIST_HEAD(ptr) ((ptr)->first = NULL)
    #define INIT_NPHLIST_NODE(ptr) ((ptr)->next = NULL)

    static inline void nphlist_add(struct nphlist_node *entry, struct nphlist_head *list) {
    struct nphlist_node *ptr = list->first;
    if (ptr) {
    while (ptr->next)
    ptr = ptr->next;
    ptr->next = entry;
    } else {
    list->first = entry;
    }
    }

    #define nphlist_entry(ptr, type, member) container_of(ptr,type,member)

    /**
    * nphlist_for_each_entry - iterate over list of given type
    * @tpos: the type * to use as a loop cursor.
    * @pos: the &struct nph_list to use as a loop cursor.
    * @head: the head for your list.
    * @member: the name of the nphlist_node within the struct.
    */
    #define nphlist_for_each_entry(tpos, pos, head, member) \
    for (pos = (head); \
    pos && ({ prefetch(pos->next); 1;}) && \
    ({ tpos = nphlist_entry(pos, typeof(*tpos), member); 1;}); \
    pos = pos->next)

    struct something {
    struct nphlist_node next;
    int v;
    };

    static NPHLIST_HEAD(data);

    int main(int argc, char *argv[]) {
    struct something *ptr;
    struct nphlist_node *p;
    int i;
    for (i = 0; i < 10; i++) {
    printf("add %d\n", i);
    ptr = malloc(sizeof(*ptr));
    INIT_NPHLIST_NODE(&(ptr->next));
    ptr->v = 10 + i;
    nphlist_add(&(ptr->next), &data);
    }
    printf("dump\n");
    nphlist_for_each_entry(ptr, p, data.first, next) {
    printf("%d\n", ptr->v);
    }
    return 0;
    }
    --- End of code ---

    Where should I put this API, in include/linux/list.h or security/tomoyo/include/tomoyo.h ?

    If I should put in include/linux/list.h , what name would be appropriate?
    May I name it "slist" instead of "nphlist" ?

    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    Hello.

    KaiGai Kohei wrote:
    > If so, you can apply RCU instead to avoid read lock
    > when scanning the list, like:
    >
    > rcu_read_lock();
    > list_for_each_entry(...) {
    > ....
    > }
    > rcu_read_unlock();


    Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
    As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't sleep.

    If I use RCU, I have to give up " [TOMOYO 13/15] Conditional permission support"
    because tmy_check_condition() can sleep.

    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [TOMOYO 05/15](repost) Domain transition handler functions.


    On Wed, 2007-10-03 at 22:59 +0900, Tetsuo Handa wrote:
    > Hello.
    >
    > KaiGai Kohei wrote:
    > > If so, you can apply RCU instead to avoid read lock
    > > when scanning the list, like:
    > >
    > > rcu_read_lock();
    > > list_for_each_entry(...) {
    > > ....
    > > }
    > > rcu_read_unlock();

    >
    > Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
    > As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't sleep.
    >
    > If I use RCU, I have to give up " [TOMOYO 13/15] Conditional permission support"
    > because tmy_check_condition() can sleep.


    You can indeed not sleep in an rcu_read_lock() section. However, you
    could grab a reference on an item, stop the iteration, drop
    rcu_read_lock. Do you thing, re-acquire rcu_read_lock(), drop the ref,
    and continue the iteration.

    Also, how do you avoid referencing dead data with your sll? I haven't
    actually looked at your patches, but the simple scheme you outlined
    didn't handle the iteration + concurrent removal scenario:

    thread 1 thread 2

    foo = ptr->next

    < schedule >

    killme = ptr->next (same item)
    ptr->next = ptr->next->next;
    kfree(killme)

    < schedule >

    foo->bar <-- *BANG*

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    Hello.

    Thank you for pointing out.

    Peter Zijlstra wrote:
    > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
    > > (1) First, ptr->next is initialized with NULL.
    > > (2) Later, ptr->next is assigned non-NULL address.
    > > (3) Assigning to ptr->next is done atomically.

    > (4) wmb after asigning ptr->next
    > (5) rmb before reading ptr->next

    Excuse me, but I didn't understand why (4) and (5) are needed.

    append_function() {

    down(semaphore_for_write_protect);
    ...
    ptr = head;
    while (ptr->next) ptr = ptr->next;
    ptr->next = new_entry;
    ...
    up(semaphore_for_write_protect);

    }

    read_function() {

    for (ptr = head; ptr; ptr = ptr->next) {
    ...
    }

    }

    Are (4) and (5) needed even when (3) is exclusively protected by down() and up() ?

    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [TOMOYO 05/15](repost) Domain transition handler functions.


    On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
    > Hello.
    >
    > Thank you for pointing out.
    >
    > Peter Zijlstra wrote:
    > > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
    > > > (1) First, ptr->next is initialized with NULL.
    > > > (2) Later, ptr->next is assigned non-NULL address.
    > > > (3) Assigning to ptr->next is done atomically.

    > > (4) wmb after asigning ptr->next
    > > (5) rmb before reading ptr->next

    > Excuse me, but I didn't understand why (4) and (5) are needed.
    >
    > append_function() {
    >
    > down(semaphore_for_write_protect);
    > ...
    > ptr = head;
    > while (ptr->next) ptr = ptr->next;
    > ptr->next = new_entry;
    > ...
    > up(semaphore_for_write_protect);
    >
    > }


    If at all possible, use struct mutex.

    > read_function() {
    >
    > for (ptr = head; ptr; ptr = ptr->next) {
    > ...
    > }
    >
    > }
    >
    > Are (4) and (5) needed even when (3) is exclusively protected by down() and up() ?


    the up() would do 4. 5 ensures another cpu will actually see it. Althoug
    in practise the various cache invalidations driven by the workload will
    ensure it will become visible eventually anyway.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    In article <200710032326.FJF32915.OQOOHLMtFSFJFV@I-love.SAKURA.ne.jp> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo Handa says:

    > Peter Zijlstra wrote:
    > > Also, how do you avoid referencing dead data with your sll? I haven't
    > > actually looked at your patches, but the simple scheme you outlined
    > > didn't handle the iteration + concurrent removal scenario:

    > Regarding my singly-linked list, no entries are removed from the list. It's append only (like CD-R media).
    > I set is_deleted flag of a entry instead of removing the entry from the list.


    It is not a good practice. Please free such objects.
    BTW, how many objects do you have in the list?

    --yoshfuji
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / ƣ wrote:

    > In article <200710032326.FJF32915.OQOOHLMtFSFJFV@I-love.SAKURA.ne.jp> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo Handa says:
    >
    > > Peter Zijlstra wrote:
    > > > Also, how do you avoid referencing dead data with your sll? I haven't
    > > > actually looked at your patches, but the simple scheme you outlined
    > > > didn't handle the iteration + concurrent removal scenario:

    > > Regarding my singly-linked list, no entries are removed from the list. It's append only (like CD-R media).
    > > I set is_deleted flag of a entry instead of removing the entry from the list.

    >
    > It is not a good practice. Please free such objects.
    > BTW, how many objects do you have in the list?


    Doesn't matter. No list should be able to grow without bounds in the
    kernel.

    --
    James Morris


  15. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    Hello.


    YOSHIFUJI Hideaki wrote:
    > It is not a good practice. Please free such objects.
    > BTW, how many objects do you have in the list?

    It varies from 0 to some thousands,
    depending on the policy supplied by the administrator and/or the policy appended by "learning mode".


    Peter Zijlstra wrote:
    > sounds like a might fine memory leak / dos attack.

    TOMOYO Linux keeps the policy in CD-R's manner.
    Thus, once an entry is written, it's pointer is valid forever.
    TOMOYO Linux's simplicity (singly-linked list with no read_lock) comes from
    this "keep the policy in CD-R's manner".
    Yes, it is a kind of memory leak, but is controllable.

    The kernel no longer requires memory after entering into "enforcing mode".
    So, attackers can't do DoS attack after entering into "enforcing mode".


    Regards.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [TOMOYO 05/15](repost) Domain transition handler functions.

    On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
    > Hello.
    >
    > Thank you for pointing out.
    >
    > Peter Zijlstra wrote:
    > > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
    > > > (1) First, ptr->next is initialized with NULL.
    > > > (2) Later, ptr->next is assigned non-NULL address.
    > > > (3) Assigning to ptr->next is done atomically.

    > > (4) wmb after asigning ptr->next
    > > (5) rmb before reading ptr->next

    > Excuse me, but I didn't understand why (4) and (5) are needed.
    >
    > append_function() {
    >
    > down(semaphore_for_write_protect);
    > ...
    > ptr = head;
    > while (ptr->next) ptr = ptr->next;
    > ptr->next = new_entry;
    > ...
    > up(semaphore_for_write_protect);
    >
    > }


    It seems to me that this function alone is a reason to argue against
    using a singly linked list. I know your patch doesn't actually contain
    this as a function but it does use the same logic to append to your
    lists. Does the overhead of the second pointer that the regular list
    head uses outweigh the O(1) insertion and deletion it provides
    (especially in your case)? I know domain transitions are rare but why
    use something with O(N) insertion? This could be one reason why there
    isn't an slist already in list.h

    Dave Quigley

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [TOMOYO 05/15](repost) Domain transition handler functions.


    About use of singly-linked list:

    What my SLL (singly-linked list) holds is bit different from other lists.

    Almost all lists hold list of elements (e.g. buffer) that are used *temporarily*.
    Thus, adding to the list and removing from the list are essential.

    My SLL holds ACL (access control list) entries that are used *permanently*
    (i.e. throughout the kernel's lifetime).
    These ACL entries are policy used for MAC (mandatory access control).
    You don't change MAC's policy without clear reason, do you?
    Therefore, ACL entries of MAC's policy seldom need to be removed.

    So I wonder
    "Remodeling the mechanism of holding ACL entries to support removal of individual entry
    worth the cost of reference-counter manipulation and the risk of dead-pointers?"

    Your next question would be
    "Why are you using SLL for holding elements that are used *permanently*?"
    "Why not allocate a large memory block and hold all elements in that block?"
    Yes, you are right. But I can't do so.
    The reason is explained in "policy file handling" at http://lkml.org/lkml/2007/10/2/56 .



    About use of list that can't remove elements:

    I think that many of you are misunderstanding about
    "When entries are automatically appended to a list".

    If you run the system in "learning mode" *forever*,
    it will consume all memory; so DoS attacks are possible.

    But please be aware that entries are automatically appended
    only while you are running the system in "learning mode".
    Also, there is a safeguard mechanism that controls upper limit.
    These lists consume less than some hundreds KB
    for embedded systems and/or targeted protection of PC systems,
    less than 1 MB for complete protection of PC systems.
    You can see how much memory is used for holding ACL entries
    via /sys/kernel/security/tomoyo/meminfo interface
    and you will find that these lists won't consume all memory in your system.

    When you are running the system in "enforcing mode",
    no entries are appended automatically; so DoS attacks are impossible.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread