>> 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 consultingat_private
Proprietor, Starshine Technical Services: http://www.starshine.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:56 PDT