Date: Sat, 18 Sep 1999 19:28:12 -0600 From: Wes Peters <wes@softweyr.com> To: Steve <sreid@sea-to-sky.net> Cc: Warner Losh <imp@village.org>, 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: <37E43C2C.69F167F9@softweyr.com> 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> <19990918012538.A1195@grok.localnet>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve wrote:
>
> 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.
There are some other holes in startup, too. I'm not sure how much we should
discuss in such a public forum, some of them might be better to air as
a fait accompli, and some are peculiar to the application I'm looking at.
> 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.
That's an interesting idea. I think it would be important to disallow such
scripts from adding to the signatures, though.
> 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.
That would be great.
> 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.
An interesting idea. One of the military systems I worked on long ago
had a background thread that would continually checksum program memory
and fault the processor if it got a checksum mismatch. Each of the
binary images were padded with checksum bytes to make the checksum match,
and the "unload" routine would restore the "transient program area" to
a known pattern.
I've often thought it would be a good idea to at least checksum executable
files, or perhaps even sign them, and modify the loader so it will refuse
to execute any executable (shared library, etc) not properly checksummed
or signed. An interesting extension to the signing mechanism would be
to require a local as well as vendor signature, so root would have to
sign an executable before it can be run on THAT system. This would obviously
require multiple local signatures for executables loaded from NFS servers.
Does this idea show merit for high-security installations?
> 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?
It's not always available (i.e. early in booting) and it doesn't tell you
about denied attempts. The lack of logging is the biggest failure from
the standpoint of a security manager.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?37E43C2C.69F167F9>