Re: comments on handbook chapter

R. B. Riddick <arne_woerner@yahoo.com> wrote:
 > Bigby Findrake <bigby@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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"