Re: HARASS ME MORE.........
On Sat, Sep 01, 2001 at 06:28:07PM +0200, Benny Kleykens wrote: > lacking this skill. Obviously few of you would give a rats-ass but Im > truly considering unsubscribing from this list, this is the second > lenghty flame-war in less than a month... maybe a moderator is needed to > keep this mailing-list pleasent and truly informative ? I think this might suggest a more moderate (and less moderated) way out of the woods. I wrote it at a time when another mailing list was having one of those flurries of "unsubscribe sent to list address" things, but it's really a general guideline for dealing with any untopical message: 1) DO NOT RESPOND TO THESE ON-LIST. 2) An informative e-mail, probably a canned response, should be sent privately. Ideally we could have a perfect filter that does this and sends exactly one such response, but duplicates aren't a problem as long as you SEE RULE #1. 3) Please apply RULE #1 when replying to those who did not themselves follow RULE #1. 4) Don't forget RULE #1, please! Of course, this requires a general interest in maintaining the list as a friendly and useful place for information exchange. IMO&E, if we haven't got that, then nothing will save us; if we do, then the overhead of moderation is purely wasted effort. -- Although we may never know with complete certainty the identity of the winner of this year's presidential election, the identity of the loser is perfectly clear. It is the nation's confidence in the judge as an impartial guardian of the law. - Justice John Paul Stevens, from his dissenting opinion Dec 12, 2000
Re: HARASS ME MORE.........
On Sat, Sep 01, 2001 at 06:28:07PM +0200, Benny Kleykens wrote: > lacking this skill. Obviously few of you would give a rats-ass but Im > truly considering unsubscribing from this list, this is the second > lenghty flame-war in less than a month... maybe a moderator is needed to > keep this mailing-list pleasent and truly informative ? I think this might suggest a more moderate (and less moderated) way out of the woods. I wrote it at a time when another mailing list was having one of those flurries of "unsubscribe sent to list address" things, but it's really a general guideline for dealing with any untopical message: 1) DO NOT RESPOND TO THESE ON-LIST. 2) An informative e-mail, probably a canned response, should be sent privately. Ideally we could have a perfect filter that does this and sends exactly one such response, but duplicates aren't a problem as long as you SEE RULE #1. 3) Please apply RULE #1 when replying to those who did not themselves follow RULE #1. 4) Don't forget RULE #1, please! Of course, this requires a general interest in maintaining the list as a friendly and useful place for information exchange. IMO&E, if we haven't got that, then nothing will save us; if we do, then the overhead of moderation is purely wasted effort. -- Although we may never know with complete certainty the identity of the winner of this year's presidential election, the identity of the loser is perfectly clear. It is the nation's confidence in the judge as an impartial guardian of the law. - Justice John Paul Stevens, from his dissenting opinion Dec 12, 2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote: > On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > machine. The machine was locked in the server room, so the only > > people who could get to the root password (and the console) were the > > people with keys. If you needed to boot to single-user, you'd rip > > which in most places includes janitors and low paid rent-a-cops. Give me physical access and I don't need your root password, though it may help make the job less detectable. But you don't get more security than you physically have to begin with. > nice way to root a box without being detected, just bring along a new > envelope and nobody will be the wiser. Except the admin who put that password into the envelope. That was one thing that seemed off in the original description, but maybe the proecess was just glossed over and the new password really is somehow installed and put on paper and into the envelope without any way for the admin who used the old one to find out what it is. Color me dubious, though. -- Neither can his mind be in tune, whose words do jarre, nor his reason in frame, whose sentence is preposterous. -- Ben Jonson
Re: shared root account
On Mon, Jul 09, 2001 at 04:18:10PM -0800, Ethan Benson wrote: > On Mon, Jul 09, 2001 at 09:33:12AM -0400, Jason Healy wrote: > > machine. The machine was locked in the server room, so the only > > people who could get to the root password (and the console) were the > > people with keys. If you needed to boot to single-user, you'd rip > > which in most places includes janitors and low paid rent-a-cops. Give me physical access and I don't need your root password, though it may help make the job less detectable. But you don't get more security than you physically have to begin with. > nice way to root a box without being detected, just bring along a new > envelope and nobody will be the wiser. Except the admin who put that password into the envelope. That was one thing that seemed off in the original description, but maybe the proecess was just glossed over and the new password really is somehow installed and put on paper and into the envelope without any way for the admin who used the old one to find out what it is. Color me dubious, though. -- Neither can his mind be in tune, whose words do jarre, nor his reason in frame, whose sentence is preposterous. -- Ben Jonson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using BIND in a chroot enviro?
On Mon, Jul 02, 2001 at 10:38:20PM -0600, Stefan Srdic wrote: > My questions are, what's the difference between a normal compilation and a > statically linked one? > > Why would you place the C libraries into your chroot tree? "Normal" means link against shared libraries. In that case, the program has to be able to access the shared libraries at run time. In static linking, the needed routines are all resolved and copies of everything the program needs are placed into its own binary. Programs that are to be run in chroots or that need to work even when the system is mostly broken - the program that's going to restore your system from tape after a crash, for example - might be statically linked so that they don't rely on the presence of shared libraries. Thanks for this interesting discussion! -- Although we may never know with complete certainty the identity of the winner of this year's presidential election, the identity of the loser is perfectly clear. It is the nation's confidence in the judge as an impartial guardian of the law. - Justice John Paul Stevens, from his dissenting opinion Dec 12, 2000
Re: Using BIND in a chroot enviro?
On Mon, Jul 02, 2001 at 10:38:20PM -0600, Stefan Srdic wrote: > My questions are, what's the difference between a normal compilation and a > statically linked one? > > Why would you place the C libraries into your chroot tree? "Normal" means link against shared libraries. In that case, the program has to be able to access the shared libraries at run time. In static linking, the needed routines are all resolved and copies of everything the program needs are placed into its own binary. Programs that are to be run in chroots or that need to work even when the system is mostly broken - the program that's going to restore your system from tape after a crash, for example - might be statically linked so that they don't rely on the presence of shared libraries. Thanks for this interesting discussion! -- Although we may never know with complete certainty the identity of the winner of this year's presidential election, the identity of the loser is perfectly clear. It is the nation's confidence in the judge as an impartial guardian of the law. - Justice John Paul Stevens, from his dissenting opinion Dec 12, 2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wierd file name?
On Sat, Jun 30, 2001 at 10:36:49PM +0200, Piotr Krukowiecki wrote: > But what bothers me is where did that file come from? > 'test' is in shellutils, but '[' is not in any of package files: > [EMAIL PROTECTED]:~$ LANG=en dpkg -S `which [` `which test` > dpkg: /usr/bin/[ not found. > shellutils: /usr/bin/test You've got to watch out for those regexp metas: $ dpkg --search "\[" shellutils: /usr/share/man/man1/[.1.gz shellutils: /usr/bin/[ $ dpkg --search "[" dpkg: [ not found. -- I didn't write a whole, free operating system, either. I wrote some pieces and invited other people to join me by writing other pieces. So I set an example. I said, "I'm going in this direction. Join me and we'll get there." And enough people joined in that we got there. -- R M Stallman
Re: Wierd file name?
On Sat, Jun 30, 2001 at 10:36:49PM +0200, Piotr Krukowiecki wrote: > But what bothers me is where did that file come from? > 'test' is in shellutils, but '[' is not in any of package files: > piotr@localhost:~$ LANG=en dpkg -S `which [` `which test` > dpkg: /usr/bin/[ not found. > shellutils: /usr/bin/test You've got to watch out for those regexp metas: $ dpkg --search "\[" shellutils: /usr/share/man/man1/[.1.gz shellutils: /usr/bin/[ $ dpkg --search "[" dpkg: [ not found. -- I didn't write a whole, free operating system, either. I wrote some pieces and invited other people to join me by writing other pieces. So I set an example. I said, "I'm going in this direction. Join me and we'll get there." And enough people joined in that we got there. -- R M Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? Not really. Not if you want to ensure that any of the data they can alter passes sanity checks despite a malicious user, which is a case you certainly have to allow for. Putting the password into a file that the user owns also allows a careless user to make it world-readable (or even writeable, eh?). Nope. SUID programs are a security risk because they offer interesting power to those who can subvert them, but they are also the way Unix systems extend restricted access to protected resources to non-root users. Rather than trying to eliminate them, which is almost certainly impossible without adding something comparable to ACLs and a raft of systemic changes (to segregate what are now fields in one record to be in separate, hence separately access-controlled files, for example), we might want to consider whether they could instead be implemented in a way that made them much less likely to be exploitable. The C language is a wonderful thing, but it offers many subtle ways to err. -- Truth in advertising is like leaven, which a woman hid in three measures of meal. It provides a suitable quantity of gas, with which to blow out a mass of crude misrepresentations into a form that the public can swallow. - Dorothy Sayers, _Murder Must Advertise_
Re: A question about Knark and modules
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote: > be SUID, you're safer without it being SUID). Is there any (sane) way > of making it so that programs such as passwd, chsh, etc. don't need to > be SUID? Not really. Not if you want to ensure that any of the data they can alter passes sanity checks despite a malicious user, which is a case you certainly have to allow for. Putting the password into a file that the user owns also allows a careless user to make it world-readable (or even writeable, eh?). Nope. SUID programs are a security risk because they offer interesting power to those who can subvert them, but they are also the way Unix systems extend restricted access to protected resources to non-root users. Rather than trying to eliminate them, which is almost certainly impossible without adding something comparable to ACLs and a raft of systemic changes (to segregate what are now fields in one record to be in separate, hence separately access-controlled files, for example), we might want to consider whether they could instead be implemented in a way that made them much less likely to be exploitable. The C language is a wonderful thing, but it offers many subtle ways to err. -- Truth in advertising is like leaven, which a woman hid in three measures of meal. It provides a suitable quantity of gas, with which to blow out a mass of crude misrepresentations into a form that the public can swallow. - Dorothy Sayers, _Murder Must Advertise_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 10:48:27PM +0200, Petr Cech wrote: > you know, what I've ment. Debian *distribution* is main and non-US/main Is that policy or your opinion? Last time I looked, there were still those pesky other sections on the servers, in the bug system, and so forth. -- You arguably have quite a few inalienable rights, but being taken seriously isn't one of them. Neither is being respected. -- Rick Moen
Re: gnupg problem
On Mon, Jun 18, 2001 at 10:48:27PM +0200, Petr Cech wrote: > you know, what I've ment. Debian *distribution* is main and non-US/main Is that policy or your opinion? Last time I looked, there were still those pesky other sections on the servers, in the bug system, and so forth. -- You arguably have quite a few inalienable rights, but being taken seriously isn't one of them. Neither is being respected. -- Rick Moen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 08:45:12PM +0100, Tim Haynes wrote: > [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > > Debian ought to offer security updates for the stable distribution, but > > it doesn't. Instead, it is only offering security updates for the > > packages in the stable distribution. That's an understandable oversight, > > but it is an oversight, and I think it should be corrected. > > Insofar as I can make any sense of the above differentiation, does the idea > `2.2r3' fit into this anywhere? Sure. That's the latest release of the distribution, with bug fixes rolled in. Many of those are security fixes. Other security fixes have been needed since release 3; because security bugs are considered more time-critical than the other sorts, they are released, and indeed we are strongly urged to install them, independently of the point release mechanism. The issue is, can a security-bug-fix release of a package which is incompatible with one or more parts of the current point release packages as a whole be good? I'm inclined to feel that this is at least a serious flaw in that security-bug-fix release, and I would hate to have to try to defend the position that it is not a release-critical grade bug. How would this sort of conflict be resolved in normal development - if this incompatibility arose in a proposed-update (non-security related), do you think that package would be accepted for the next point release? I would hope not. > > We are not just about packages, we are about the way they work together > > to form a coherent whole. What he said. Debian's biggest plus - I speak here as a sysadmin and user of the distro - has always been the much higher technical quality; having a supposed "fix" cause another part of Debian to break seems quite antithetical to that quality. If I wanted to roll the dice every time I installed something new I could be using RPMs. :-( :-) -- Microsoft, which used to say all the time that the software business was ruthlessly competitive, is now matched against a competitor whose model of production and distribution is so much better that Microsoft stands no chance of prevailing in the long run. They're simply trying to scare people out of dealing with a competitor they can't buy, can't intimidate and can't stop. -- Eben Moglen
Re: rlinetd security
On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote: > Well, it depends. You can never tidy up a rooted box; the same mentality > sort of applies all the way down - if you're setting up a box, why worry > about installing this and uninstalling that, when your original > installation shouldn't have had anything enabled in the first place? (And > yes, you can push that back into the distro, too.) Sure, you can have a distro that doens't install any services. Heck, consider local exploits and you may decide that "login considered harmful" isn't too great a stretch... :-) I have to take issue with your attempt to draw a aparallel to a rooted box. It *is* possible to cleanup the newly installed box because you can reasonably assume that it hasn't been maliciously setup to resist the cleanup. > Surely software you install on production machines has its requirements > either satisfied by the wonder that is apt-get, or documented properly? You > can, and should, start from blank and add things as you need. Could I agree with the minimalist sentiment while yet observing that apt-get, wonderful as it is, cannot satisfy requirements that come not from packages installed on this machine, but from other machines - possibly ones that aren't even using Debian? At the same time, I would like to agree with the sentiment that has been expressed a few times. "If you don't know what it's for, shut it off." I think the unstated part that some may have overlooked is that if you need something but don't know it, then you owe it to yourself (and your employers, if that's the sort of situation it is) to find out what's there. This is how sysadmins lose their hair! -- There has grown up in the minds of certain groups in this country the notion that because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. -- RAH
Re: gnupg problem
On Mon, Jun 18, 2001 at 08:45:12PM +0100, Tim Haynes wrote: > [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > > Debian ought to offer security updates for the stable distribution, but > > it doesn't. Instead, it is only offering security updates for the > > packages in the stable distribution. That's an understandable oversight, > > but it is an oversight, and I think it should be corrected. > > Insofar as I can make any sense of the above differentiation, does the idea > `2.2r3' fit into this anywhere? Sure. That's the latest release of the distribution, with bug fixes rolled in. Many of those are security fixes. Other security fixes have been needed since release 3; because security bugs are considered more time-critical than the other sorts, they are released, and indeed we are strongly urged to install them, independently of the point release mechanism. The issue is, can a security-bug-fix release of a package which is incompatible with one or more parts of the current point release packages as a whole be good? I'm inclined to feel that this is at least a serious flaw in that security-bug-fix release, and I would hate to have to try to defend the position that it is not a release-critical grade bug. How would this sort of conflict be resolved in normal development - if this incompatibility arose in a proposed-update (non-security related), do you think that package would be accepted for the next point release? I would hope not. > > We are not just about packages, we are about the way they work together > > to form a coherent whole. What he said. Debian's biggest plus - I speak here as a sysadmin and user of the distro - has always been the much higher technical quality; having a supposed "fix" cause another part of Debian to break seems quite antithetical to that quality. If I wanted to roll the dice every time I installed something new I could be using RPMs. :-( :-) -- Microsoft, which used to say all the time that the software business was ruthlessly competitive, is now matched against a competitor whose model of production and distribution is so much better that Microsoft stands no chance of prevailing in the long run. They're simply trying to scare people out of dealing with a competitor they can't buy, can't intimidate and can't stop. -- Eben Moglen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote: > Well, it depends. You can never tidy up a rooted box; the same mentality > sort of applies all the way down - if you're setting up a box, why worry > about installing this and uninstalling that, when your original > installation shouldn't have had anything enabled in the first place? (And > yes, you can push that back into the distro, too.) Sure, you can have a distro that doens't install any services. Heck, consider local exploits and you may decide that "login considered harmful" isn't too great a stretch... :-) I have to take issue with your attempt to draw a aparallel to a rooted box. It *is* possible to cleanup the newly installed box because you can reasonably assume that it hasn't been maliciously setup to resist the cleanup. > Surely software you install on production machines has its requirements > either satisfied by the wonder that is apt-get, or documented properly? You > can, and should, start from blank and add things as you need. Could I agree with the minimalist sentiment while yet observing that apt-get, wonderful as it is, cannot satisfy requirements that come not from packages installed on this machine, but from other machines - possibly ones that aren't even using Debian? At the same time, I would like to agree with the sentiment that has been expressed a few times. "If you don't know what it's for, shut it off." I think the unstated part that some may have overlooked is that if you need something but don't know it, then you owe it to yourself (and your employers, if that's the sort of situation it is) to find out what's there. This is how sysadmins lose their hair! -- There has grown up in the minds of certain groups in this country the notion that because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. -- RAH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 045-1] ntp remote root exploit fixed
On Thu, Apr 05, 2001 at 01:37:33PM -0500, Nathan E Norman wrote: > Myriad bugs in bind. Beaucoup. You meant to say "beaucoup bugs in bind." :-) Thanks to the team for the prompt action, BTW.
Re: [SECURITY] [DSA 045-1] ntp remote root exploit fixed
On Thu, Apr 05, 2001 at 01:37:33PM -0500, Nathan E Norman wrote: > Myriad bugs in bind. Beaucoup. You meant to say "beaucoup bugs in bind." :-) Thanks to the team for the prompt action, BTW. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MD5 sums of individual files?
On Thu, Mar 29, 2001 at 01:04:47PM -0600, Kenneth Pronovici wrote: > Another option would be to not store the AIDE configuration file anywhere > that the cracker could see it. Without that configuration file, the > cracker would have no way to generate a valid, substitute list of > checksums. This is less workable, because that configuration file would > have to be "unhidden" every time AIDE needed to run, making a cron-based > schedule more difficult. Well, if the cracker is really good, you can't trust anything less than a boot from physically secure media (and one that doesn't trust anything on the system that's not physically secured) to run the scan anyway. :-( As you say, the scan's config has to be visible to him, so even if you ship the results off to another box for comparison with the "known good" signatures, all he has to do is install a fake scan program. This answers against nearly all checks less intrusive than a secure boot. Luckily, most crackers aren't capable of such subtlety... and so keeping the checklist on write-protected media is a reasonable approach. But security is a process, not a cron job. ;-)
Re: MD5 sums of individual files?
On Thu, Mar 29, 2001 at 01:04:47PM -0600, Kenneth Pronovici wrote: > Another option would be to not store the AIDE configuration file anywhere > that the cracker could see it. Without that configuration file, the > cracker would have no way to generate a valid, substitute list of > checksums. This is less workable, because that configuration file would > have to be "unhidden" every time AIDE needed to run, making a cron-based > schedule more difficult. Well, if the cracker is really good, you can't trust anything less than a boot from physically secure media (and one that doesn't trust anything on the system that's not physically secured) to run the scan anyway. :-( As you say, the scan's config has to be visible to him, so even if you ship the results off to another box for comparison with the "known good" signatures, all he has to do is install a fake scan program. This answers against nearly all checks less intrusive than a secure boot. Luckily, most crackers aren't capable of such subtlety... and so keeping the checklist on write-protected media is a reasonable approach. But security is a process, not a cron job. ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
