[lkml]   [2005]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector
    On Mon, 2005-02-21 at 08:07 +0100, Guillaume Thouvenin wrote:
    > On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote:
    > > On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
    > > > It's a new patch that implements a fork connector in the
    > > > kernel/fork.c:do_fork() routine. The connector sends information about
    > > > parent PID and child PID over a netlink interface. It allows to several
    > > > user space applications to be alerted when a fork occurs in the kernel.
    > > > The main drawback is that even if nobody listens, a message is send. I
    > > > don't know how to avoid that. I added an option (FORK_CONNECTOR) to
    > > > enable the fork connector (or disable) when compiling the kernel. To
    > > > work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
    > > > has been tested on a 2.6.11-rc3-mm2 kernel with two user space
    > > > applications connected.
    > > >
    > > > It is used by ELSA to manage group of processes in user space. In
    > > > conjunction with a per-process accounting information, like BSD or CSA,
    > > > ELSA provides a per-group of processes accounting.
    > >
    > > I think people will complain here...
    > > ... [cut here] ...
    > > I still think that lsm with all calls logging is the best way to
    > > achieve this goal.
    > I agree with you. My first implementation was with LSM but Chris Wright
    > (I think it was him) notice that it's not the right framework (and it
    > seems true). So I looked for another solution. I though about kobject
    > but it was too "big" and finally, Greg KH spoke about connectors. It's
    > small and efficient.

    Your do_fork() change really looks like either audit addon(but it is
    not the case) or LSM logging facility.
    I think adding cn_netlink_send() in every function in security/dummy.c
    and renaming it to security/cn_logger.c or something is not such a bad
    Or even wait in each function until userspace replies with the decision
    allow or not such call.
    Although it can create a lock (need to recheck security hooks in
    send/recv pathes).

    > > from the other side why only fork is monitored in this way?
    > The problem is the following: I have a user space daemon that manages
    > group of processes. The main idea is, if a parent belongs to a group
    > then its child belongs to the same group. To achieve this I need to know
    > when a fork occurs and which processes are involved. I don't see how to
    > do this without a hook in the do_fork() routine... Any ideas are
    > welcome.

    Now I begin to understand Chris Wright - LSM are designed not for
    but only for initialisation path - i.e. LSM will say only if something
    is allowed or not,
    but not if it was performed.

    So, for exactly your setup there is no any other way then to patch

    > Thank you Evgeniy for all your comments about the code, it helps and I
    > will modify the patch.
    > Regards,
    > Guillaume
    Evgeniy Polyakov

    Crash is better than data corruption -- Arthur Grabowski
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:10    [W:0.023 / U:21.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site