> Hi all,
>
> 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')
>
> 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):
Hi,
Please see:
(or some similar address), and search though Orange-Linux -> Linux-privs.
There is a patch there that extends the concept of securelevel to be a
bitmap, and actually makes things like immutable etc. genuinely secure.
> 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)
The combined patches cater for most of the important ones of these, and
also take care of other "root ways to batter at the disk" such as
ioperm()/iopl() etc., and some raw drive commands.
> Can anyone here provide a summary of how that worked?
I think the tradition is that only init (pid 1) may change the securelevel
value to a less secure one than it currently is at. Unfortunately, it was
possible to fiddle with the init process's image in memory via /proc/1/mem
or something similar like that. This is taken care of in the Linux
patches.
> Where can I find the 'sysctl' command?
It is a kernel function. RTM; man sysctl
> What would a sample 'sysctl' command to increase securelevel
> look like?
It is most conveniently done via the /proc interface (enabled once more
in the latest patches on the above site),
ie. echo "some new value" > /proc/sys/kernel/securelevel
> What other features will be accessible via the sysctl(8)
> command?
Anything under /proc/sys/
> 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?
securelevel is fine to be written to this way. /proc/sys entries
containing multiple values to be written may cause problems unless your
shell issues all the numbers with a single write() call.
> Reducing 'securelevel' is supposed to require a
> shutdown? Would this necessarily close all remote
> connections to all network and other non-console devices?
A shutdown or a hacked-up init. Shutdowns do indeed tend to close network
connections ;-)
> How do the current securelevel features affect
> X Windows? SVGAlib? IPFW? Other "stuff"?
Some of these things stop working in high security mode; it is necessary
to deny X write access to /dev/kmem and iopl(). It tries to use both. I
hope GGI will one day provide a solution for this problem! :)
> Would it be fair to say that the Linux-Privs (Orange Linux)
> work is not likely to be in the 2.2 kernel?
ACL's for ext2 are partially written it would seem. They might well make
2.2 (drool). Don't hold your breath for the auditing stuff, but the
splitting of root privs into capabilities could well be on target. (more
drooling -- good security stuff this)
Chris