Date: Sat, 16 Mar 2002 09:23:28 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Jeff Jirsa <jjirsa@hmc.edu> Cc: freebsd-hackers@freebsd.org, arr@freebsd.org Subject: Re: logging securelevel violations Message-ID: <Pine.NEB.3.96L.1020316091906.13304R-100000@fledge.watson.org> In-Reply-To: <002001c1c936$c25ff4d0$5e3bad86@boredom>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Mar 2002, Jeff Jirsa wrote: > I've noticed that currently, violations of securelevel are aborted, but not > typically logged. It seems like in addition to aborting whichever calls are > in progress, logging an error might be beneficial. I recognize that this > goes along the same lines as logging file permission errors, but if a file > is marked immutable, the implicit value of the file should suggest that one > might want to be able to audit attempted changes to that file. <...> > Would the following not work? <...> > log(LOG_ERR, "Unable to load module %s: securelevel violation \n", <...> > So, my questions are: Why shouldn't it be done? What simple problems am I > overlooking? (Would such a contribution have a chance of making it into > 5.0?) It would work, certainly, but I guess the question is whether it's useful and/or desirable. The first concern I'd have is that the message is inaccurate: it's not a violation, it's a denial of a request. The security policy hasn't been violated, it's actually been enforced. Second, my concern would be whether this is useful. First off, securelevels are an inconsistent policy, and easy to work around as an attacker without ever generating any of these warnings. Second, these warnings would be generated during normal operations, as a number of applications attempt to load kernel modules when they need them, including ppp. Generating spurious warnings as part of normal system activity isn't necessarily a useful activity, and tends to result in more calls for help on questions@. What would be far more desirable is a general framework for auditing, something that Andrew Reiter <arr@FreeBSD.org> has been working on (CC'd). I'm not sure what his current status is, but presumably reporting securelevel check failures would fit well into the framework. Depending on his progress, it may be that any contributions that you could make towards bring the framework to fruition would be much appreciated :-), be it requirements information, other suggestions, or code :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020316091906.13304R-100000>