Re: Proposal "LUID": CAPP requirements

From: Jan Harkes (jaharkes@cs.cmu.edu)
Date: Mon Apr 17 2000 - 19:12:35 EST


On Mon, Apr 17, 2000 at 03:53:47PM -0700, Linda Walsh wrote:
> Jan Harkes wrote:
> > How is this less secure than the luid?
> > How is this [not] usable as an equivalent to the luid?
> ---
> It provides less flexibility in the user space to implement
> policy. For example. I've been mulling over how to solve the daemon vs.
> root conundrum. It seems that first thing init might do is set_luid(daemon).

Let's bring back the capabilities stuff. I actually believe we might be
getting somewhere.

    static int global_audit_counter = 1;

    int sys_newauditid(void)
    {
        lock_kernel();

        if (current->auditid && !capable(CAP_NEW_AUDIT_ID))
            return -EPERM;

        current->auditid = global_audit_counter++;

        unlock_kernel();

        return 0;
    }

    int sys_getauditid(void)
    {
        return current->auditid;
    }

I can see 3 policies that results from this implementation:

    - unsecure system.
        Everyone has CAP_NEW_AUDIT_ID, equivalent to PAG semantics as
        used by AFS.

    - moderately secure system.
        Only trusted daemons have CAP_NEW_AUDIT_ID, and drop it as soon
        as they pass control to the user. If someone manages to hacks
        into the system through the trusted daemon and calls new_auditid
        he simply asks for being audited. Ofcourse named/sendmail
        wouldn't necessarily fall in the category of trusted daemons.

    - secured system.
        Nobody gets CAP_NEW_AUDIT_ID, once you get marked with an
        audit-id, you're stuck with it.

> an incoming user (including root) and *drop* CAP_SETLUID. So normal
> even root couldn't change it again directly. Root would have to use
> some sort of direct I/O / writing to memory at the right spot, etc.
> no problem for a knowlegable and determined attacker, but that isn't what
> this feature is aimed for.

Or load a module that modifies "current->whatever" etc. True, a really
secured systems needs a lot more things tied down.

Jan

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



This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:12 EST