Date: Sat, 18 Sep 1999 01:25:39 -0700 From: Steve <sreid@sea-to-sky.net> To: Warner Losh <imp@village.org> Cc: Brett Glass <brett@lariat.org>, Liam Slusser <liam@tiora.net>, Kenny Drobnack <kdrobnac@mission.mvnc.edu>, "Harry M. Leitzell" <Harry_M_Leitzell@cmu.edu>, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <19990918012538.A1195@grok.localnet> In-Reply-To: <199909172208.QAA05554@harmony.village.org>; from Warner Losh on Fri, Sep 17, 1999 at 04:08:18PM -0600 References: <4.2.0.58.19990917160519.047cc890@localhost> <Your <4.2.0.58.19990916185341.00aaf100@localhost> <4.2.0.58.19990916185341.00aaf100@localhost> <Pine.GSO.3.96.990916150427.5757E-100000@mission.mvnc.edu> <4.2.0.58.19990917160519.047cc890@localhost> <199909172208.QAA05554@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 17, 1999 at 04:08:18PM -0600, Warner Losh wrote:
> In message <4.2.0.58.19990917160519.047cc890@localhost> Brett Glass writes:
> : Sounds like a job for an automatic utility!
>
> Yes. Automation would help. Today you almost have to do
> chflags schg /usr/{s,}bin/* /{s,}bin/* /usr/libexec/* /etc/* /usr/lib/*
> to get started, but even that leaves a few holes...
I think the boot scripts should be redesigned to do only what is really
necessary pre-securelevel, raise the securelevel ASAP, then pass control
to post-securelevel scripts. Keep the chflags requirements to a
minimum. I sort of plan to do this for my own systems.
Really, I have slightly more grandiose plans, mainly allowing remote
sysadmin (that's me) to upload scripts and have them run
pre-securelevel: stick them in a directory, reboot, and have the boot
process run them after verifying PGP signatures (and sequence numbers to
prevent replay attacks). For those times when you just _have_ to fix a
vulnerability involving a schg file but can't get to the console for a
while. This of course conflicts somewhat with my previous paragraph.
I would be happy to share such a boot process if/when I actually get
around to doing it. I don't think it would be very difficult.
As for automating the lock-down procedure, I would suggest a change be
made to the kernel such that it can print warnings when an unprotected
binary or library is used, and also when an unprotected file is opened.
By "unprotected" I mean one that is not schg, OR who's parent
directories are not sufficiently protected to prevent stuff being moved
around. At the start of the boot process enable the warnings and then
disable them after securelevel is raised. If you get any of these
theoretical warnings about a binary or library, fix it. If you get such
warnings on an unprotected file, make sure you know what it's about. A
reasonable flag for these warnings might be kern.securelevel==0 (as in,
"It's not -1 because I really do want to raise the securelevel, but I'm
vulnerable at the moment, so tell me if I do anything risky").
Unfortunately I don't know enough about the kernel to make such a
change.
BTW, what are these deficiencies people are talking about with
securelevel? When properly configured it seems to me to be well suited
to stopping an intruder from going invisible with trojaned ls, ps,
syslogd, tripwire, etc. No more, no less. Or am I missing something?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990918012538.A1195>