I'm writing another article for SysAdmin Magazine -- and I need
some answers to some questions:
I'll be talking about the Linux ext2fs "immutable" and
"append-only" attributes (as set by 'chattr' and viewed
with 'lsattr') and the kernel 'securelevel' feature
(visible under /proc/sys/kernel/ and settable by 'sysctl')
(BTW: I've spent hours searching FAQ's, Yahoo!, Alta Vista,
SavvySearch, and ML archives for answers to these questions.
My search has netted me just enough to ask more detailed
questions here -- but please don't tell me to RTFM unless
you can point to a specific FM to R).
Here are the main questions:
When were the immutable and append-only flags
added to the ext2fs? (which kernel version 1.0?
.99?)
When were the chattr and lsattr commands made
available? (same time, I hope)
What is the current state of the securelevel feature?
(it seems to be "read-only" in the 2.0.30 kernels --
is it "stable" in the 2.1.5x betas?)
What restrictions, precisely, are imposed at each
securelevel? (below are my impressions -- please correct
as necessary or confirm):
0 -- none
1 -- disable chattr's (only on clearing -i and -a?)
disable writes to kmem
disable writes to raw block devices
disable loadable modules (except for kerneld?)
mount restricted to exact options/records
specified in /etc/fstab ?
clock/time settings can't be changed?
mark stack segments as noexec? (vmm)
???
(others?) -- ???
Can anyone here provide comparisons to the
{Free|Net|Open}BSD 'securelevel'?
Has anyone here read about the bug in *BSD 4.4 /proc fs
that allows users to circumvent its 'securelevel'?
Can anyone here provide a summary of how that worked?
Does it appear that Linux' kernel would have a similar
vulnerability? Has that been fixed?
Where can I find the 'sysctl' command?
What would a sample 'sysctl' command to increase securelevel
look like?
What other features will be accessible via the sysctl(8)
command?
I've heard that a write() to /proc/sys/kernel/securevel
should allow one to increase the 'securelevel' setting.
Would a shell command such as 'echo 1 > ....' work for
that? If not, why not?
Reducing 'securelevel' is supposed to require a
shutdown? Would this necessarily close all remote
connections to all network and other non-console devices?
Has anyone tried to reduce securelevel via a serial
console? Where could I find a URL or pointer to info
about serial/modem console support? (Those were unofficial
patches, weren't they?)
How do the current securelevel features affect
X Windows? SVGAlib? IPFW? Other "stuff"?
What are the outstanding questions about how securelevel
"should" work? Are there any open debates on the topic?
Do any of you have any opinions about immutability and
securelevel that you'd like to see expressed to the
sysadmin community at large?
That about covers the 'securelevel' stuff.
I also have some other kernel/security related questions.
How would/will ACL's be added to ext2fs? Would/could we
add a more generalized ACL's mechanism that would work with
other filesystems? What support commands would/will we
require to set and view ACL's (HP-UX chacl/lsacl, or Solaris
setacl/getacl?)?
How will this be stored "under the hood?" Will we have to
implement some sort of kernel database (a la Netware's bindery)?
Could this be implemented by having the Kernel load/register a
"reference monitor daemon" of some sort?
How would the proposed ACL's features correspond/compare to
Netware? NT (yuck!)? VMS? Multics? (<grin>).
Would it be fair to say that the Linux-Privs (Orange Linux)
work is not likely to be in the 2.2 kernel?
That project proposal seems to require some changes to the
ext2 fs. It appears that the GNU HURD project is also using
a modified ext2 fs. How will will all these variants of
ext2 be integrated back together? Will they?
A number of discussions have raged in Linux newsgroups and
mailing lists about a Linux/VM of some sort -- that is some
sort of restructuring to reduce the impact of untrusted code
on the security of the core OS. I gather people are suggesting
a multi-ringed (x86 specific?) approach similar to Netware 4.x
There have also been requests for "signed binaries" or "deferred
system call" interfaces (to do things like seletively monitoring
and/or controlling the chown() for some/all processes).
Do any of those make any sense to the developers on this list?
Which, if any, of these features are likely to see the light
of day? When?
What other security features would be nice to see in the Linux
kernel? What sorts of features would allow more of the security
to be *securely* implemented outside of the the kernel (i.e.
what sort of "access/security reference monitor" interface could
be provided)?
I'd sincerely like to thank each of you for your tolerance and patience
with this long message. I'm sure it's obvious that I'm more of a writer
than a programmer -- and I'm not a kernel hacker at all.
My hope, with this article, is to present some compelling reasons for
SA's readers to adopt Linux -- and to contribute to its further development.
That is specifically why I'm doing an overview of "cutting edge" (alpha
and beta) features.
I'd especially like to slow SA's slide down that slippery slope towards
Microsoft's OS'!
(Just try to read that out loud ... 3 times ... really fast).
--
Jim Dennis (800) 938-4078 consulting@starshine.org
Proprietor, Starshine Technical Services: http://www.starshine.org
PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org>
Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A