comments on handbook chapter
Oliver Fromme
olli at lurza.secnetix.de
Mon Sep 11 09:17:50 PDT 2006
R. B. Riddick <arne_woerner at yahoo.com> wrote:
> Bigby Findrake <bigby at ephemeron.org> wrote:
> > Travis H. wrote:
> > > Wouldn't it be better to detect /and/ prevent an attempt to change the
> > > system binaries?
> >
> > That's how I interpret that passage from the handbook - that you should
> > detect *and* prevent. I'm not clear on how anyone is interpreting that
> > passage to suggest that unequal weight should be given to one side or the
> > other (detection vs. prevention). The above passage all but says, "don't
> > do X because that will interfere with Y." I just don't see that advice as
> > advocating imbalance.
> >
> Hmm...
>
> I think, this "schg flag"-thing should be done to all files, but invisible to a
> potential attacker... <-- PROTECTION
There's no need to make it "invisible". First, it wouldn't
add anything to the protection. And second, it could be
called a case of "security by obscurity".
> When some attacker tries to get write access to that file or to move that file
> around or so, it should result in a log message (like "BAD SU on ...")... <--
> DETECTION (I think one of the first messages in this thread suggested that
> already...)
That can be done with the AUDIT framework that has recently
been MFCed to 6-stable.
> And removing that flag shouldn't be possible so easy, too.
What do you mean, "so easy"? It's not easy. The flag can only
be removed if security level < 1. Once the system is running
at >= 1, lowering the security level requires a reboot. Please
see the init(8) manual page for details.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"I invented Ctrl-Alt-Delete, but Bill Gates made it famous."
-- David Bradley, original IBM PC design team
More information about the freebsd-security
mailing list