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
Re: load spike strangeness
> At 4:48 AM -0800 2000/1/9, Amancio Hasty wrote: > > For instance, just because someone has an email name which resembles > > a real name lets say "Brad Knowles" does not necessarily mean that the > > real "Brad Knowles is sending the mail assuming of course that there > > is a Brad Knowles. > > I've built up enough history over the years (all the while using > my real name and a real e-mail address, although the address has > changed over the years as I've changed employers, etc...) that you > can go do some AltaVista or Hotbot searches and find enough stuff > that I've written that we can be reasonably sure that this really is > me. I may not be proud of some of the stupid things I've done or > said over the years, but I'll own up to them regardless. > > I'd say that the same is probably true of most of the people > posting to the various lists. We have a new existential proof, "I'm archived, therefore I am"! :-) Seriously, Brad, I'm not convinced that you're anything more than a complex PERL program until I meet you in person. Particularly since you seem to have more time and energy to spend posting to Usenet and mailing lists than anyone else I know. ;-) ... 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: need patch review - NFS fixes for IP binding
> interfaces (e.g. virtual frame interfaces). 'named' went the
> 'bind to everything' route and it was six years before the bugs got
> worked out of it.
And, despite those efforts, some of us went and bludgeoned the code into
a more trivial case ("bind to address nn.nn.nn.nn") for local use anyways.
Looks like the jail code will do something similar w/o source changes.
Oh well!
... 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: 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: 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: 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
> On Fri, Apr 14, 2000 at 05:21:24PM -0500, Joe Greco wrote: > > 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. > > Sounds all basically like a good idea to have different choices > for a MTA. > > But I don't like _basic_ system functionalities to be out sourced > completely to ports. Why not? They already are. You're kidding yourself if you think that the FreeBSD project is maintaining Sendmail and BIND. > Two examples: > > If I give people a FreeBSD-STABLE snapshot CD, I'd like to give > them a complete Unix, and for me a MTA belongs to a basic package. > > If I want to do a complete upgrade of all of my system ports, > because I come to the conclusion > - I installed to much experimental crap and don't get it > sorted out manually > - or I want to upgrade everything to the latest and greatest > I don't want to kill my MTA (sendmail) by performing a rm -rf /usr/local/* > action. Then solve _that_particular_problem_. For example, as I outlined several years ago, define "built-in" packages, which, when you do a "pkg_delete sendmail", actually nukes what is (now) in /usr/libexec/sendmail*, /etc/sendmail.cf, etc. Then, when you do a "pkg_add sendmail", well, I don't know if there's more merit to putting the executables in the /usr/libexec directory (I think my preference would be not to do that) or in /usr/local... but one of those. A really clever implementation would be to set up this stuff as install components, and then you can have sysinstall "select" the Sendmail component automatically for normal installs, but leave it up to the guy who's doing the Custom install. If not selected, none of Sendmail is installed. If selected, Sendmail is installed, as a component, but also as a package, so that doing "pkg_delete" removes /usr/libexec/sendmail* and friends. Of course, none of this is particularly new. I proposed it years ago, as a way to cut down on various forms of system bloat (not everyone needs perl5, or Sendmail, or BIND, or UUCP, or the C compiler) and to allow for easier upgrades of individual system components that are, in fact, NOT PART OF THE SYSTEM. They actually come from outside vendors, and are generally things that require upgrading more often than the actual Real-Base-Of- FreeBSD does. > FreeBSD - as is - has all the basic system functionality in the > base system and I wouldn't like to have a "neutral" "castrated" > Unix just for the sake, that you can start later to customize > things like sendmail and maybe other things Whee. Where's the GUI? I fail to be impressed! Yet it does not seem to be an issue that X11 isn't part of the base system. It is just something that is made easy to install, and in fact, users might not realize that X11 isn't "part of" FreeBSD. Hell, I'm proposing something that is much closer to a seamless system to include or remove the components in question than what we do with XFree86, yet the XFree86 solution is acceptable to us... > > I would love to see this happen with other components of the system as > > well, such as BIND. > > definitively not. I hate the Linux way to have a puzzle system. You have it now. Running BIND? Hope it's a recent version. Otherwise, poof. All sorts of problems. Got that ancient 2.2.5 system laying in the back closet? Didn't upgrade Sendmail? Heaven help you when somebody finds an exploit for your old Sendmail. We should make it easy to update parts of the system that realistically may _require_ updating in order to maintain the security of the overall system. We should not make it a "go figure it out, newbie" type project for beginning users to perform an upgrade of some essential networking utility, the next time an obvious root exploit is released. > Again FreeBSD != Linux. FreeBSD != Linux. FreeBSD == crap-for-ease-of-upgrading-or-replacing-built-in-packages. Linux == closer to that goal from what I've seen. This == bad for FreeBSD. > > 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. :-/ > > Well ... for that purpose I'd vote for the following: > > a) make more > NO_ (sendmail, bind, whatever) >knobs in /etc/make.conf as neede
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: anonymous-ftp cracked
> Ted: I've been watching this one because I've HAD to allow uploads to > incoming because of a need for such a place article submissions from our > Tech mag website from 175+ countries. > > Your tips for monitoring (like the script for a daily listing of the > directory) are so simple and obvious it put a smile on my face. Thanks! LUV > this list! Assuming you're using wuftpd: You may have to allow incoming, but perhaps you don't have to allow downloads of /incoming. Think about it. :-) Alternatively, wuftpd has a very nice notification feature that will mail you when something is submitted. Some of us do have good reasons for allowing both-way incoming access. Make sure your /incoming directory is unreadable in any case... > From [EMAIL PROTECTED] Thu Sep 13 18:42:44 2001 > Return-Path: <[EMAIL PROTECTED]> > Date: Thu, 13 Sep 2001 18:42:41 -0500 (CDT) > From: wu-ftpd <[EMAIL PROTECTED]> > Subject: New file uploaded: file.tmp > To: undisclosed-recipients:; > > jgreco@ uploaded /incoming/file.tmp from 206.55.xxx.xxx. > File size is 504586240. > Please move the file where it belongs. This has the advantage of being almost instantaneous. After an @Home wanker decided to fill a few gigabytes on snarchive, creating a denial-of-service to the legitimate users, I turned this on. Now when somebody tries to use me for their warez, I accidentally corrupt a bunch of bytes in their files. So far, they seem to have gotten the message, because I've only seen one unauthorized file attempted upload this week. >:-> -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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]"
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 s
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, cod
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 > but not " 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.
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
