Re: Security Hole in Axent ESM

[jimd () STARSHINE ORG (Jim Dennis)]

> > Yes. Process capability restrictions. CAP_TIME or something like that could
> > be easily implemented.

> Looks like it already has.  (Except that capabilities still aren't in the
> ext2 code of mainstream kernels, are they?)

> Look in kernel 2.1.119 at include/linux/capability.h, lines 246-250 and
> kernel/time.c, lines 155-160.

> --Patrick

        Yes, some kernel support for POSIX.1e (or is it POSIX.6)
        "capabilities" (which I refer to as "privileges") are
        implemented in recent Linux 2.1.x kernels.

        No, there is currently no support for storing these
        settings in the ext2 filesystem.

        What I really want from the whole mess is a way to
        implement 'securelevel' --- and I'm told that these
        "privileges" will allow one to emulate most 'securelevel'
        features.  This CAP_TIME feature is one of those.

        I don't know if they/we will have to write a userspace
        'sysctl' command (like FreeBSD, et al) or make this into
        a directory under /proc (requiring me to echo magic values
        into magic nodes thereunder) or what.

        Hopefully they'll have enough support in the kernel so
        that *some* sort of userspace 'securelevel' features
        can be implemented.

        (I've BCC'd their kernel mailing list on this message).

        Hopefully we won't have a rehash of the old debate about
        whether 'securelevel' is "really" secure and whether this
        or that workaround or implementation bug makes the whole
        concept (or POSIX.1e privs) "completely worthless" etc.

        Those who are interested in such debates are welcome to
        search through archives of this ml and of the comp.unix.security
        ng.  I personally maintain that even a slightly flawed
        'securelevel' or 'privs' implementation will still thwart
        *some* script kiddies some of the time.  Even if I'm wrong,
        there's enough sysadmins and managers who want features like
        this that a best effort is called for.

        (Obviously a major flaw that actually reduces the overall
        security is not acceptable).

        The main features I want to enable are restrictions on
        'chattr' (~ BSD 'chflags') --- to prevent clearing the
        "immutable" and "append-only" flags --- and the ability
        to prevent remounting 'ro' filesystems in 'rw' mode.
        I realize that for these to be really effective it is
        also necessary to disable various forms of raw device,
        kmem, and I/O permissions access.

        From what I remember of the last linux-kernel... discussion
        on this topic the suggestion was that this would be
        implemented by revoking various privs from the 'init' process.
        I suppose some other privs might be revoked from the inetd
        and other network daemon processes.  I don't know if this
        would be implemented as a set of patches to 'init' (to
        read these through /dev/initctl ?) or what.

        In any event hopefully the features in the 2.1 kernels
        are sufficient for some userspace utility.  I know that
        the development crew is currently in "feature freeze"
        so I know that nothing else in this field is likely to be
        done before 2.2 is "shipped."

--
Jim Dennis  (800) 938-4078              consulting () starshine org
Proprietor, Starshine Technical Services:  http://www.starshine.org