Re: logging securelevel violations
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
At 09:23 16-3-2002 -0500, Robert Watson wrote: 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@. I don't know. Today I had someone who had trouble installing a new kernel. I asked him what secure level he used and he didn't know. Turned out he had selected the SECURE profile in the installer and had securelevel 2. If the kernel had spewed a message at him saying something like Cannot remove file with current securelevel or likewise he would have been able to figure it out on his own. When you try to write to a file and normal file permissions deny you this action don't you get a permission denied? It's just an error message informing the user something can't be done because of a specific reason. If a user can't load kernel modules that he needs for ppp, wouldn't you rather have him ask I get this message about securelevel when I try to use ppp and it doesn't work instead of ppp doesn't work and I don't know why? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
On Sat, 16 Mar 2002, Rogier R. Mulhuijzen wrote: At 09:23 16-3-2002 -0500, Robert Watson wrote: 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@. I don't know. Today I had someone who had trouble installing a new kernel. I asked him what secure level he used and he didn't know. Turned out he had selected the SECURE profile in the installer and had securelevel 2. If the kernel had spewed a message at him saying something like Cannot remove file with current securelevel or likewise he would have been able to figure it out on his own. Arguably, we shouldn't be exposing securelevels to users who might turn them on by accident, since the model doesn't actually provide much if any protection in the default shipped configuration. When you try to write to a file and normal file permissions deny you this action don't you get a permission denied? It's just an error message informing the user something can't be done because of a specific reason. The permission denied message on writing to a file isn't because of securelevels, it's because of the file flags on the file. The only effect of securelevels on the UFS implementation is in the file flag change call, where change requests are denied based on securelevels. Probably, if a file flag is set and the install program can't remove it, it should print that the file flag can't be removed, possibly due to securelevels. If a user can't load kernel modules that he needs for ppp, wouldn't you rather have him ask I get this message about securelevel when I try to use ppp and it doesn't work instead of ppp doesn't work and I don't know why? If the userland application gets back EPERM from an attempt to load a kernel module, it should either work around the failure as appropriate, or print an appropriate error message to the user regarding the failure. Note that not all module loading is fatal for the application, and so it may not be a failure condition for the application. Under those circumstances, printing a kernel message would not be helpful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
On 2002-03-12 08:29, Rogier R. Mulhuijzen wrote:
At 02:36 12-3-2002 +0200, Giorgos Keramidas wrote:
Rate limiting is still needed:
while true ;do
echo /dev/ad0
echo /dev/ad1
done
This would cause syslogd to go nuts!
crw-r- 2 root operator 116, 0x00010002 Jan 20 03:13 /dev/ad0
Only if you're root.
Well, you get the idea. I meant that syslog will catch the repetitive
messages, only if no other messages are sent between the two or more lines
that match :-(
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
At 16:07 12-3-2002 +0200, Giorgos Keramidas wrote: On 2002-03-12 08:29, Rogier R. Mulhuijzen wrote: At 02:36 12-3-2002 +0200, Giorgos Keramidas wrote: Rate limiting is still needed: while true ;do echo /dev/ad0 echo /dev/ad1 done This would cause syslogd to go nuts! crw-r- 2 root operator 116, 0x00010002 Jan 20 03:13 /dev/ad0 Only if you're root. Well, you get the idea. I meant that syslog will catch the repetitive messages, only if no other messages are sent between the two or more lines that match :-( What I meant is, the file permissions on /dev/ad0 stop ordinary users from even reaching the point where the secure level denies the attempt. And so only root can actually trigger the secure level violation log message. So it cannot be used to maliously fill the logs. Unless someone has root, and then you have bigger problems. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
On 2002-03-12 22:26, Rogier R. Mulhuijzen wrote:
What I meant is, the file permissions on /dev/ad0 stop ordinary users from
even reaching the point where the secure level denies the attempt.
And so only root can actually trigger the secure level violation log
message. So it cannot be used to maliously fill the logs. Unless someone
has root, and then you have bigger problems.
Indeed. But we're discussing something about code that doesn't exist.
Rate limiting is not bad, IMHO. But I'll let this go, until we have code
to work on. I'm just concerned that there might be things that securelevel
would disallow, that can be done by ordrinary users. For instance if user
mounts are allowed, mounting a partition or floppy disk etc.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
RE: logging securelevel violations
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. I think this would be useful, but I would be concerned about the rate at which these messages could come when someone is actively attacking a system. Perhaps such messages could go through a rate limiter mechanism similar to that now used by the network interfaces. I am not certain whether this addition would affect the TrustedBSD work, either. Guy Helmer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: logging securelevel violations
I think this would be useful, but I would be concerned about the rate at which these messages could come when someone is actively attacking a system. Perhaps such messages could go through a rate limiter mechanism similar to that now used by the network interfaces. syslogd already has a last message repeated N times Also most things you do that are negated by securelevel you can only do as root, so I don't see how someone without elevated privileges could fill up your logs with these messages anyway. These audit messages could be a nice way of finding out that someone has root when they shouldn't. And if root is compromised you have bigger things to worry about then overflowing log files. I personally think this would be very useful. Maybe supply a sysctl for turning on and off. And for the newbies in the house turn it on by default. That way the Why can't I get this to work? caused by securelevel settings would be answered a lot quicker. I'm still a junior kernel hacker myself, but I'd say this would be a perfect junior kernel hacker project. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
On 2002-03-11 22:00, Rogier R. Mulhuijzen wrote:
I think this would be useful, but I would be concerned about the rate at
which these messages could come when someone is actively attacking a
system.
Perhaps such messages could go through a rate limiter mechanism similar to
that now used by the network interfaces.
syslogd already has a last message repeated N times
Rate limiting is still needed:
while true ;do
echo /dev/ad0
echo /dev/ad1
done
This would cause syslogd to go nuts!
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: logging securelevel violations
At 02:36 12-3-2002 +0200, Giorgos Keramidas wrote: On 2002-03-11 22:00, Rogier R. Mulhuijzen wrote: I think this would be useful, but I would be concerned about the rate at which these messages could come when someone is actively attacking a system. Perhaps such messages could go through a rate limiter mechanism similar to that now used by the network interfaces. syslogd already has a last message repeated N times Rate limiting is still needed: while true ;do echo /dev/ad0 echo /dev/ad1 done This would cause syslogd to go nuts! crw-r- 2 root operator 116, 0x00010002 Jan 20 03:13 /dev/ad0 Only if you're root. Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
