Messages in this thread | | | Date | Thu, 03 Sep 1998 19:22:12 -0700 | From | Jim Dennis <> | Subject | Re: Security Hole in Axent ESM |
| |
------- Blind-Carbon-Copy
To: Patrick <patrick@CS.VIRGINIA.EDU> cc: BUGTRAQ@NETSPACE.ORG X-Mailer: MH 8.6.3 Subject: Re: Security Hole in Axent ESM In-Reply-to: <Pine.LNX.4.02.9809021445480.8491-100000@bootp-150-57.bootp.virginia.edu> Message Apparently From Patrick <patrick@CS.VIRGINIA.EDU> Dated Wed, 02 Sep 1998 14:50:57 EDT. Date: Thu, 03 Sep 1998 19:22:12 -0700 From: Jim Dennis <jimd@canopus.starshine.org>
>> 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
------- End of Blind-Carbon-Copy
- 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/faq.html
| |