Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote:
I've got a weirdness with kill(2).
This code is out of Diablo, the news package, and has been working fine for
some years. It apparently works fine on other OS's.
In the Diablo model, the parent process may choose to tell its children to
update status via a signal. The loop basically consists of going through
and issuing a SIGALRM.
This stopped working a while ago, don't know precisely when. I was in the
process of debugging it today and ran into this.
The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as
well.
Perhaps the children are setuid, the parent doesn't have appropriate
privelege and you are mistaken about this happening under 4.8 as well.
Well, the parent process does the code I listed below early on in the
initialization process - it pretty much does a little initialization,
opens its socket (119), sheds privilege, and begins accepting conns.
It then forks off processes for each connection.
The program itself is not a suid executable, but rather relies on being
launched by a root user.
I'm not sure what appropriate privilege would be. If both the uid/euid
of the parent match both the uid/euid of the child, I would expect to be
able to kill the process...
Client complains about the resulting problems also happening under 4.8
servers. Dunno. Could possibly be a separate issue.
In 5.x since at least rev.1.80 of kern_prot.c, only certain signals
not including SIGALRM can be sent from unprivileged processes to setuid
processes.
This is very UN-unixlike although it is permitted as an-implementation-
defined restriction in at least POSIX.1-2001. It breaks^Wexposes bugs
in some old POSIX test programs and I don't have many security concerns
so I just disable it locally:
%%%
Index: kern_prot.c
===
RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.175
diff -u -2 -r1.175 kern_prot.c
--- kern_prot.c 13 Jul 2003 01:22:20 - 1.175
+++ kern_prot.c 17 Aug 2003 04:26:00 -
@@ -1395,4 +1387,5 @@
return (error);
+#if 0
/*
* UNIX signal semantics depend on the status of the P_SUGID
@@ -1425,4 +1418,5 @@
}
}
+#endif
/*
%%%
Wot? Why can't I send it a signal?
I've read kill(2) rather carefully and cannot find the reason. It says,
For a process to have permission to send a signal to a process designated
by pid, the real or effective user ID of the receiving process must match
that of the sending process or the user must have appropriate privileges
(such as given by a set-user-ID program or the user is the super-user).
The implementation-defined restrictions are not documented, of course ;-).
Well, the sending and receiving processes both clearly have equal uid/euid.
We're not running in a jail, so I don't expect any issues there.
The parent process did actually start as root and then shed privilege with
struct passwd *pw = getpwnam(news);
struct group *gr = getgrnam(news);
gid_t gid;
if (pw == NULL) {
perror(getpwnam('news'));
exit(1);
}
if (gr == NULL) {
perror(getgrnam('news'));
exit(1);
}
gid = gr-gr_gid;
setgroups(1, gid);
setgid(gr-gr_gid);
setuid(pw-pw_uid);
so that looks all well and fine... so why can't it kill its own children,
and why can't I kill one of its children from a shell with equivalent
uid/euid?
Changing the ids is one way to make the process setuid (setuid-on-exec is
another but that doesn't seem to be the problem here). The relevant setuid
bit (P_SUGID) is normally cleared on exec, but perhaps it isn't here,
either because the children don't exec or the effective ids don't match
the real ids at the time of the exec.
The children aren't spawned via exec, but clearly they have equal
uid/euid's.
So what you're saying, I guess, is it's not supposed to work.
I guess I'm a bit confused by the logic of this. I've seen numerous
forking daemons over the years that do this sort of thing (not to mention
I've written a number). I've always viewed shedding root privs as being a
good thing... Was it really intended to break things in this manner?
I know there's been some paranoia about signal delivery and all that, but
my searching hasn't turned up anything that would explain this. Certainly
the manual page ought to be updated if this is a new expected behaviour or
something... at least some clue as to why it might fail would be helpful.
Certainly. It is incomplete even not counting complications for jails
or other implementation-defined restrictions related to appropriate
privilege.
Sigh.
Thanks for the note,
... JG
--
Joe Greco - sol.net Network
Re: Someone help me understand this...?
On Wed, 27 Aug 2003, Joe Greco wrote: The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as well. Could you confim this happens with 4.8? The access control checks there are substantially different, and I wouldn't expect the behavior you're seeing on 4.8... Rather difficult. I'll see if the client will let me trash a production system, but usually people don't like $40K servers handing out a few hundred megabits of traffic going out of service. We were trying to fix it on the scratch box (which happens to have 5.1R on it) and then were going to see how it fared on the production systems. The man page definitely needs to be updated, but I think it's worth having a conversation about whether the current behavior is too conservative first... These changes come in response to a class of application vulnerabilities relating to the delivery of unexpected signals. The reason the process in question is being treated as special from an access control perspective is that it has undergone a credential change, resulting in the setting of the process P_SUGID bit. This bit remains set even if the remaining credentials of the process appear normal -- i.e., even if ruid==euid, rgid==egid, and can only be reset by calling execve() on a normal binary, which is considered sufficient to flush the state of the process. These processes are given special protection properties because they almost always have cached access to memory or resources acquired using the original credential. For example, the process accesses the password file while holding root privilege, which means that the process may well have password hashes in memory from its reading the shadow password file -- in fact, it likely even have a file descriptor to the shadow password file still open. The same P_SUGID flag is used to prevent against unprivileged debugging of applications that have changed credentials and now appear normal. P_SUGID is also used to determine the results of the issetugid() system call, which is used by many libraries to see if they are running with (or have run with) privilege and need to behave in a more conservative manner. Okay, well, that makes good sense. I don't remember the details, but there have been at least a couple of demonstrated exploits of vulnerable applications using signals in which setuid applications rely on certain signals (such as SIGALRM, SIGIO, SIGURG) only being delivered as a result of system calls that set up timers, IO, etc. I seem to recall it might have involved a setuid application such as sendmail on OpenBSD, but I'll have to do some googling and get back to you. These protections probably fall into the same class of conservative behavior as our preventing setuid programs from being started with closed stdin/stdout/stderr descriptors. Giving up privilege without performing an exec() is very difficult in UNIX, unfortunately, since the trappings of privilege may be maintained by libraries, etc, without the knowledge of application writers. Right now, signal delivery in 5.x is pretty conservative if a process has changed credentials, to protect against tampering with a class of applications that has, historically, been vulnerable to a broad variety of exploits. I've attached an (untested) patch that makes this behavior run-time configuration using a sysctl -- when the sysctl is disabled, special-case handling for P_SUGID processes is disabled. I believe that this will cause the problem you're experiencing in 5.x to go away -- please let me know. Well, I'm hoping more for a general fix for Diablo, rather than a special patch for the OS. Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. I wonder if it would be reasonable to have some sort of interface that allowed a program to tell FreeBSD not to set this flag... if not, at least if there was a sysctl, code could be added so that the daemon checked the flag when starting and errored out if it wasn't set. BTW, it's worth noting that the mechanism Diablo is using to give up privilege actually does retain some privileges -- it doesn't, for example, synchronize its resource limits with those of the user it is switching to, so it retains the starting resource limits (likely those
Re: Someone help me understand this...?
On Thu, 28 Aug 2003, Joe Greco wrote: On Wed, 27 Aug 2003, Joe Greco wrote: The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as well. Could you confim this happens with 4.8? The access control checks there are substantially different, and I wouldn't expect the behavior you're seeing on 4.8... Rather difficult. I'll see if the client will let me trash a production system, but usually people don't like $40K servers handing out a few hundred megabits of traffic going out of service. We were trying to fix it on the scratch box (which happens to have 5.1R on it) and then were going to see how it fared on the production systems. I think it's safe to assume that if you're seeing a similar failure, there's a different source given my reading of the code, but I'm willing to be proven wrong. It's probably not worth the investment if you're talking about large quantities of money, though. It's more like large quantities of annoyance and work. Can you describe the case you're envisioning? If I can easily poke at it, I can at least get some clues. Clearly, unbreaking applications like Diablo by default is desirable. At least OpenBSD has similar protections to these turned on by default, and possibly other systems as well. As 5.x sees more broad use, we may well bump into other cases where applications have similar behavior: they rely on no special protections once they've given up privilege. I wonder if Diablo can run unmodified on OpenBSD; it could be they don't include SIGALRM on the list of protect against signals, or it could be that they modify Diablo for their environment to use an alternative signaling mechanism. Another alternative to this patch would simply be to add SIGARLM to the list of acceptable signals to deliver in the privilege-change case. I wonder if it would be reasonable to have some sort of interface that allowed a program to tell FreeBSD not to set this flag... if not, at least if there was a sysctl, code could be added so that the daemon checked the flag when starting and errored out if it wasn't set. We actually have such an interface, but it's only enabled for the purposes of regression testing. If you compile options REGRESSION into the kernel configuration, a new system call __setsugid(), is exposed to applications. It's used by src/tools/regression/security/proc_to_proc to make it easier to set up process pairs for regression testing of inter-process access control. When I added it, there was some interest in just making it setsugid() and exposing it to all processes. Maybe we should just go this route for 5.2-RELEASE. Invoking it with a (0) argument would mean the application writer accepted the inherrent risks. However, this would open the application to the risks of debugging attachment, which are probably greater than the signal risks in most cases. It's not clear what the best way to express I want to accept these risks but not those risks would be... So far, it sounds like we have three work-arounds in the pot, perhaps we can think of something better: (1) Remove SIGALRM from the list of prohibited signals in the P_SUGID case. Not clear what the risks are here based on common application use, but this is an easy change to make. (2) Add setsugid() to allow applications to give up implicit protections associated with credential changes. This comes with greater risks, I suspect, since it opens up applications to more explicit vulnerabilities: signal attacks require more sophistication and luck, but debugging attacks are easy. (3) Allow administrators to selectively disable the more restrictive signal checks at a system scope using a sysctl. This is easy, and comes with no risks as long as the setting is unchanged (the default in the patch I sent out earlier). I'm tempted to commit (1) immediately to allow a workaround if we get nothing else figured out, and to think some more about (2) and (3). Another possibility would be to encourage application writers to avoid overloading signals that already have meanings, and rely on the USR signals. I assume the reason Diablo uses ALRM is that the USR signals already have assigned semantics? Correct. The USR signals control debug levels. If it was a signal that was only used internally, it could be changed, of course, but changing a signal used by humans (and one used in the same manner as other programs) is probably a bad idea. BTW, it's worth noting that the mechanism Diablo is using to give up privilege actually does retain some privileges -- it doesn't, for example, synchronize its resource limits with those of the user it is switching to, so it retains the starting resource limits (likely those of the root account). That's actually preferred in most cases. News servers almost always eat far more
Someone help me understand this...?
I've got a weirdness with kill(2).
This code is out of Diablo, the news package, and has been working fine for
some years. It apparently works fine on other OS's.
In the Diablo model, the parent process may choose to tell its children to
update status via a signal. The loop basically consists of going through
and issuing a SIGALRM.
This stopped working a while ago, don't know precisely when. I was in the
process of debugging it today and ran into this.
The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as
well.
%echo $$
29047
%ps -O ruid,uid | egrep '28949|29045|29047'
28949 8 8 p0 I 0:00.00 diablo: ihav=0chk=0rec=0 ent=0
29045 8 8 p0 I 0:00.00 sleep 99
29047 8 8 p0 D 0:00.01 -su (csh)
%kill -ALRM 28949
28949: Operation not permitted
%kill -ALRM 29045
%ps -O ruid,uid | egrep '28949|29045'
28949 8 8 p0 I 0:00.00 diablo: ihav=0chk=0rec=0 ent=0
%
Wot? Why can't I send it a signal?
I've read kill(2) rather carefully and cannot find the reason. It says,
For a process to have permission to send a signal to a process designated
by pid, the real or effective user ID of the receiving process must match
that of the sending process or the user must have appropriate privileges
(such as given by a set-user-ID program or the user is the super-user).
Well, the sending and receiving processes both clearly have equal uid/euid.
We're not running in a jail, so I don't expect any issues there.
The parent process did actually start as root and then shed privilege with
struct passwd *pw = getpwnam(news);
struct group *gr = getgrnam(news);
gid_t gid;
if (pw == NULL) {
perror(getpwnam('news'));
exit(1);
}
if (gr == NULL) {
perror(getgrnam('news'));
exit(1);
}
gid = gr-gr_gid;
setgroups(1, gid);
setgid(gr-gr_gid);
setuid(pw-pw_uid);
so that looks all well and fine... so why can't it kill its own children,
and why can't I kill one of its children from a shell with equivalent
uid/euid?
I know there's been some paranoia about signal delivery and all that, but
my searching hasn't turned up anything that would explain this. Certainly
the manual page ought to be updated if this is a new expected behaviour or
something... at least some clue as to why it might fail would be helpful.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenSSH and PAM
While I realize that 4.0 has PAM'ified SSH, I was wondering if anyone was planning to extend this in the manner that telnet/rlogin have been. From /etc/pam.d/login: auth sufficient pam_tacplus.so try_first_pass template_user=staffer Basically this'll grab the "staffer" account and use it as the basis for other arbitrary users who have been authenticated by TACACS. Very handy at an ISP where you may wish to allow or disallow access to many servers to a large number of individuals who tend to come and go. The people who don't _really_ need to access the machines on a daily basis just get a TACACS login and they get to live with the "template" user's dotfiles etc. Unfortunately, sshd does some explicit checks with getpwnam() that cause ssh connectins to fail if the user is not in /etc/passwd, and there are probably other issues as well. Any ssh hackers looking at this, by any chance? -- ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, 14 Apr 2000, Joe Greco wrote: In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ I always keep hearing the same line. You guys *know* perfectly well how to do it, and it's not a big thing to you, you even admit it's only "a bit of a pain". To most of the rest of the world, it's a huge thing, and they don't have the least clue how to do it. If you guys want so desperately to make things 1% easier, why have I never seen anyone bring out a parallel "sparse" FreeBSD? It wouldnt' be a large thing to do, and you who keep on asking for it, you know that very well. Just have a reasonable bit of compassion for everyone else. That's not to say the huge hurt it would do to FreeBSD to all reviewers and the public at large, just to save you "a bit of a pain". Uh, Chuck, can you tell me how many BIND and Sendmail advisories there have been in the last five years? Wouldn't it be nice if we could just tell newbies, "hey, yeah, that Sendmail has a known security issue, pkg_delete it and then add this new one here". Or would you prefer to explain to someone who doesn't "have the least clue how to do it" how to upgrade BIND and Sendmail to the latest? The concept is beneficial from _many_ angles, not just the one I gave. Despite my tendency to promote the traditional BSD distribution style, that does not mean that I feel that everything in FreeBSD should arrive as it did on the 4.4BSD tape. I think that the ability to be able to select modules for inclusion or exclusion would be particularly useful. ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Uh, Chuck, can you tell me how many BIND and Sendmail advisories there have been in the last five years? Wouldn't it be nice if we could just tell newbies, "hey, yeah, that Sendmail has a known security issue, pkg_delete it and then add this new one here". Or would you prefer to explain to someone who doesn't "have the least clue how to do it" how to upgrade BIND and Sendmail to the latest? The concept is beneficial from _many_ angles, not just the one I gave. Despite my tendency to promote the traditional BSD distribution style, that does not mean that I feel that everything in FreeBSD should arrive as it did on the 4.4BSD tape. I think that the ability to be able to select modules for inclusion or exclusion would be particularly useful. If you want to pick another one and by default install that, fine. If you want to force new users to read all about mailers just to get their first mail working, no, that's just too much, Joe, you're asking too much of folks. If you've got a bone to pick with sendmail, that's ok, but you have to pick a better one. If you can't decide on the best one, then how in the heck do you expect Joe Public to do better? ALWAYS provide sensible default values, not a bunch of expert questions. Chuck, Please go back and read what I _wrote_. Your response assumes I made statements that I certainly did not, and suggests to me that you missed every third word in my previous messages. :-( In particular, I advocated including Sendmail in the base system in a manner that would allow it to be trivially removed (or, alternatively, not including it but making it a selectable package, like X11). This could, for example, be done in the very same way that we currently do loads of other crap, like /usr/games, proflibs, etc. More ideally, it would be done in a format compatible with the package management system, so that one could simply "pkg_delete" Sendmail and install a new one. Am I getting through now? :-) -- ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Chuck, Please go back and read what I _wrote_. Your response assumes I made I've got your message, I quoted it fully in my first response. You asked to "Remove Sendmail from the base system", and that's a direct quote, Joe. Yes. That doesn't mean that it can't come with FreeBSD... manpages, games, proflibs, even X11, none of those are part of the base system, but people find their way to installing them. Somehow. Also, you've completely ignored that there was a latter half to that sentence. "Hmm." I love creative quoting, and I really have an aversion to being made to say something that I didn't, like "let's force users to choose a mailer". -- ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
At 2:44 PM -0400 2000/4/9, Patrick Bihan-Faou wrote: The advantage would be that we can have a fairly decent qmail configuration using the standard make world feature. Is there any interest in that kind of work ? Considering the number of qmail-specific pieces that need to be installed to support it (and the resulting domino effect), the highly negative impacts that qmail is notorious for, and that it is not intended to be a drop-in replacement for sendmail, I would be highly opposed to this change. If we are actively interested in finding a replacement for the open-source sendmail MTA, I would prefer one that was designed from the beginning with security in mind (including going so far as being intended to run in a chroot() environment), is intended to avoid undesirable behaviour as much as possible, and is intended to be a drop-in replacement for sendmail to the greatest degree possible. In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ -- ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, Apr 14, 2000 at 05:21:24PM -0500, Joe Greco wrote: While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ man mailwrapper No, that's not what I'm talking about. If you want to install the latest Sendmail, what do you do? (hint: it has nothing to do with mailwrapper) I'd like it to be something like: # pkg_delete sendmail; pkg_add sendmail Right now, to do a chrooted sendmail, not only do you have to remove the pre-existing sendmail: # chmod 000 /usr/sbin/sendmail /etc/sendmail.cf (etc etc) but you also have to do some things to install it chrooted someplace safe. Some of us also view the concept of having to actually change executables within the base system as something nearing criminal. I _really_ like the idea of mounting my systems RO and very secure. Changing modes on files doesn't bother me so much, but I'd prefer not to do it. The ideal situation would be where sendmail did not come installed by default. -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
The patch previously mentioned has completely fixed my problem, as far as I
can tell.
routetbl 13117K 25K 40960K936240 0 16,32,64,128,256
after a day of uptime.
here's mine..
this is from a single homed machine, with a default route. it's also a IRC
server (irc.stanford.edu), with a LOT of filtering of inbound traffic.
FreeBSD 3.3-STABLE #8: Sat Nov 27 17:15:49 PST 1999
11:33PM up 2 days, 20:41, 1 user, load averages: 0.03, 0.03, 0.00
routetbl 20529K 10489K 10489K 34799600 0 16,32,64,128,256
note that the table maxed out at some point (during a DoS attack.)
root-irc.stanford.edu-[11:34pm-52]#t netstat -ran | wc
70 4094741
looks like it leaked 135 in 2.8 days..
-- Welcome My Son, Welcome To The Machine --
Bob Vaughan | techie@{w6yx|tantivy}.stanford.edu | [EMAIL PROTECTED]
| P.O. Box 9792, Stanford, Ca 94309-9792
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --
--
... Joe
---
Joe Greco - Systems Administrator [EMAIL PROTECTED]
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
Have any of you been seeing route table leaks in -current? I noticed this week that cvsup-master.freebsd.org is suffering from them. I actually had to reboot it because it couldn't allocate any more. From the "vmstat -m" output: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) [...] routetbl150907 21221K 21221K 21221K 4621840 0 16,32,64,128,256 [...] I can think of some experiments to try in order to start to diagnose it. But first, have any of you seen this problem? Hell, I've been seeing this for well over a year. The last time I mentioned it, everybody seemed to think I was nuts. :-) FreeBSD 3.0-19981015-BETA #1: Tue Jan 12 03:30:56 CST 1999 routetbl289178 40961K 40961K 40960K 4357410 0 16,32,64,128,256 When it gets like that, it starts losing the ability to add further ARP table entries and essentially starts going randomly deaf to local hosts (and to a lesser extent remote hosts). I've also seen it on a 3.3-RELEASE box, but it's not currently happening to any of them right now. Machines in question are SMP boxes, and get hit fairly heavily in various Usenet news server roles. Seems to happen quite a bit more often on boxes that talk to a wide variety of host types, and I can't recall having seen it on boxes that only talk to other FreeBSD boxes. But that could also be because the network environment is much more controlled internally. ... Joe ------- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
Hell, I've been seeing this for well over a year. The last time I mentioned it, everybody seemed to think I was nuts. :-) FreeBSD 3.0-19981015-BETA #1: Tue Jan 12 03:30:56 CST 1999 routetbl289178 40961K 40961K 40960K 4357410 0 16,32,64,128,256 Well, I havent seen problems of this nature (yet), but for reference, netstat -nr | wc 69585 419164 4875822 routetbl143718 19653K 21229K 21229K 65271520 0 16,32,64,128,256 FreeBSD 3.3-RC #0: Wed Sep 8 13:37:19 EDT 1999 uptime 9:44AM up 90 days, 20:35, 2 users, load averages: 0.00, 0.01, 0.00 This is a border router with 2 views of the net running defaultless. Yeah, nice :-), but the machine I'm looking at is one with a default route and netstat -rn | wc -l 16 Most of which are routes pointing at the 3 private-net interfaces on the machine. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
At 08:51 AM 12/8/99 -0600, Joe Greco wrote: Most of which are routes pointing at the 3 private-net interfaces on the machine. The info was provided more as a comparison, that quantity of routes do not necessary mean leak ? Or perhaps it does. But after 90 days, you would think the problem would have been hit no ? My _point_ was that this issue (or some variant) has been around for some time. I suspect it doesn't have to do with packet forwarding, but does somehow have to do with machines that actually establish or receive TCP connections. Why this only affects certain types of systems, I don't know. Certainly a large number of routes doesn't mean anything. However, vmstat -m | grep routetbl|grep K routetbl289178 40961K 40961K 40960K 4357410 0 16,32,64,128,256 netstat -rn | wc -l 16 289178 blocks (and 40960K - that's 40MB) in use to support 16 routes (that is 2.5MB of memory used per listed route) is a bit on the excessive side. Your example was more along the lines of 20MB to support 65000 routes, only a few hundred bytes per route, which is roughly on the order of what I'd expect per route. I'd think that inbound connections are less likely to be an issue than outbound ones, as inbound connections get really heavily exercised on things like web servers. But that is off-the-top-of-my-head speculation, and I've nothing to support that theory. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
: :At 1:26 PM -0600 1999/12/8, Joe Greco wrote: : : vmstat -m | grep routetbl|grep K : routetbl289178 40961K 40961K 40960K 4357410 0 :16,32,64,128,256 : netstat -rn | wc -l :16 Please use 'netstat -rna' to get a listing of *all* the routes, including the temporary ones, not just the non-temporary routes. -Matt netstat -rna |wc -l 17 netstat -rn | wc -l 16 arp -an |wc -l 0 (yes, really) I'm not sure a more recent box would be different. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: utmp last
Why do we store the utmp/wtmp and last logs in different data
structures?
What seems strange is that they use the different data types to
store the same information (the time):
struct lastlog {
time_t ll_time;
charll_line[UT_LINESIZE];
charll_host[UT_HOSTSIZE];
};
struct utmp {
charut_line[UT_LINESIZE];
charut_name[UT_NAMESIZE];
charut_host[UT_HOSTSIZE];
longut_time;
};
Not that there is any _real_ difference between long and time_t,
but it would imagine we'd want to be as consistant as possable.
Anyhow, IMHO the umtp filestructure should be used to store the
last log. At the same time, I'm sure there is a reason for
the way things are. Could someone clue me in?
Good programmers don't waste space.
In particular, since the lastlog format uses the uid as the index into
the file, when the format was designed, the maximum file size would have
been 28 * 65536 ~= 1.8MB. By comparison, your suggestion bloats it up
to 36 * 65536 ~= 2.4MB - to add a completely useless field. Now, that
may not seem like a lot, but there was a time and day when we were
installing on 40MB hard drives and were in complete awe at how much space
we had. I remember my first serious FreeBSD box on a pair of 30MB RLL's.
This, of course, assumes the 8-character name that was in use at the time
this format was devised.
Now that we have 32-bit UID's, and 16-character names, it is a bit more
significant... although it is possible to argue that the lastlog format
itself is broken. Defining one really big uid (oh, let's say 2^32-1)
results in a 114GB-sized file, although it is likely to be sparse. :-)
This is still a problem for sparse-unaware utilities. Your approach
would yield a 180GB-sized file. I'm not sure what advantage this extra
66GB waste (that's 37% waste!) would provide.
Your point about time storage is correct, however, I believe. Using
long instead of time_t is just asking for problems. There's probably
some hysterical raison for it.
... Joe
---
Joe Greco - Systems Administrator [EMAIL PROTECTED]
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Bad attitudes (was Re: DoS from local users)
Wow, this is getting deep. Mikhail, give it a break. You _cannot_ prevent a determined attacker from cauing a system a lot of heartache. For every subsystem that you harden, you introduce new weaknesses and more performance hits which can themselves be used as vulnerabilities. I'd bet my reputation on being able to DoS any box you can present to me, given sufficient technical knowledge of the box and what measures you have implemented. Now, PHK, Matt Dillon, Jordan, and all these other fine hackers are hammering out code for this fine OS, and each has their own area of interest and specialty. (I don't mean to leave anyone out BTW). Each is doing their own bit to make the OS better. Sometimes you will be able to get one of them interested in a particularly good idea, sometimes you won't. There have often been things I've wanted to see in FreeBSD, and sometimes you just have to go hammer out the code yourself and submit it. I've done my own bits... anyone who looks at getty or some of the SLIP code will find my fingerprints on them. Sometimes I've talked people into doing useful things... John Dyson, thanks for madvise(), just for example. Is FreeBSD ideal for a public shell system? No. Yet it is a hell of a lot better than Solaris, which many ISP's use. It's a hell of a lot better than SunOS, which _I'VE_ used for a decade to provide public shell access. If you want to run a public shell system, you have to do so with your eyes wide open. You have to be an experienced admin, willing to take some time to make it work right, or you have to be a clueless newbie admin who is willing to live on the box 24/7. Once you establish this, then any help the OS provides merely falls into the wonderful fantastic safety net category. Now, if you'd LIKE the OS to provide a wonderful fantastic safety net, then by all means, STFU and go write one. I'm continually amazed at the fantastic improvements being introduced into FreeBSD on a regular basis... ... Joe --- Joe Greco - Systems Administrator jgr...@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
