Re: Help! File permissions keep changing...

2004-02-19 Thread François TOURDE
Le 12466ième jour après Epoch, Michael Stone écrivait: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be nice if

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone: On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Are you less secure today than yesterday? No.

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jean Christophe ANDRÉ
Le jeudi 19 fvrier 2004 09h24 (+0100), Jan Lhr crivait : What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Warning: the Linux kernel has a well known serious leak, you should shut all your servers

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread m
Hello, Another question : it is possible to control arp protocol packets by kernel ? ... if so - this will solve some of problems. But how control arps? perhaps on firewall ? kern 2.4.24/grsec/... You can adjust the refresh timer by setting /proc/sys/net/ipv4/neigh/*/gc_stale_time, or

unsubscribe

2004-02-19 Thread Asi Ettlin
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lhr
Greetings, Am Donnerstag, 19. Februar 2004 09:39 schrieb Jean Christophe ANDR: Le jeudi 19 fvrier 2004 09h24 (+0100), Jan Lhr crivait : What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Warning:

Re: Help! File permissions keep changing...

2004-02-19 Thread Russell Coker
On Thu, 19 Feb 2004 09:12, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread Adam ENDRODI
On Thu, Feb 19, 2004 at 10:37:50AM +0100, m wrote: Control, I mean as doing proxy arp only for special IP's not for all, or etc.. I do not have any idea :( This is more important from day to day for me :( I have some hakers;) in my networks who trying to spoof another computers, If I turn

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited disclosure and no disclosure at all. No vendor currently offers what once was

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). -- To UNSUBSCRIBE, email to [EMAIL

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie: Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings, Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie: Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings, Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie: Jan Lühr wrote: But the dominance of the CERT is excactly the point I'm criticising. CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jose Alberto Guzman wrote: It may be better to set a deadline for the disclosure, instead of a coordinated disclosure. A deadline is some form of coordination, although a rather unidirectional one. 8-) Often, more flexibility is desirable. OTOH, it may also help to coordinate the actual

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't believe in money don't support CERT/CC either because CERT/CC is selling the information they collect via the Internet Security

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use 'em today. Probably yes. If the costs for software production were one or

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lhr
Greeting,. Am Donnerstag, 19. Februar 2004 15:12 schrieb Florian Weimer: Jan Lühr wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Michael Stone
On Thu, Feb 19, 2004 at 02:22:19PM +0100, Florian Weimer wrote: There's an implicit contract among GNU/Linux distributors: you wait with disclosure until most parties are ready. Red Hat rushed ahead several times and the company still has early access to information. Red Hat screwed up a few

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread Jose Alberto Guzman
m wrote: Hello, Another question : it is possible to control arp protocol packets by kernel ? ... if so - this will solve some of problems. But how control arps? perhaps on firewall ? kern 2.4.24/grsec/... You can adjust the refresh timer by setting /proc/sys/net/ipv4/neigh/*/gc_stale_time, or

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread m
Hello, JAG MAC addresses can be easily changed (spoofed) with ifconfig's hw JAG option. So they can't be trusted. Better look into ipsec if you really JAG care about authenticity, plus you get pretty good encryption with it as JAG well. of course, I know about them, thanks :) But I want to

2.2 Kernel Fix

2004-02-19 Thread John Darrington
Are we going to see a patch for the recent mremap() problem for the 2.2 series of kernels, sincee they're apparently vulnerable too? J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 02:30:54PM +0100, Florian Weimer wrote: Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: Jan L?hr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable,

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread s. keeling
Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). You seem to imply that one is better off with a proprietary software

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread John Galt
On Wed, 18 Feb 2004, Michael Stone wrote: On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote: May I ask you what local / remote root exploit-fixes are you holding back currently? no. we won't hide problems my tired ass. -- The Internet must be a medium for it is neither Rare nor Well

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 09:12:42PM -0700, s. keeling wrote: Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary).

Carzy braagins on xnaax

2004-02-19 Thread Mcnamara
eagle relaxation leaden madras meson mitosis quadrant congratulatory salaam transferred flatulent statesmen credential biota horoscope banister tampon edit superb biochemic legacy polemic cavern ,euridyce yea broomcorn kinesic acquisitive invidious bridegroom stipulate

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread s. keeling
Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 09:12:42PM -0700, s. keeling wrote: Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Bernd S. Brentrup
On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on him won't work either :-), he'll

Re: Help! File permissions keep changing...

2004-02-19 Thread François TOURDE
Le 12466ième jour après Epoch, Michael Stone écrivait: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be nice if

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone: On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? Are you less secure today than yesterday? No.

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jean Christophe ANDRÉ
Le jeudi 19 février 2004 à 09h24 (+0100), Jan Lühr écrivait : What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days. Warning: the Linux kernel has a well known serious leak, you should shut all your

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread m
Hello, Another question : it is possible to control arp protocol packets by kernel ? ... if so - this will solve some of problems. But how control arps? perhaps on firewall ? kern 2.4.24/grsec/... You can adjust the refresh timer by setting /proc/sys/net/ipv4/neigh/*/gc_stale_time, or

unsubscribe

2004-02-19 Thread Asi Ettlin

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings, Am Donnerstag, 19. Februar 2004 09:39 schrieb Jean Christophe ANDRÉ: Le jeudi 19 février 2004 à 09h24 (+0100), Jan Lühr écrivait : What about establishing some kind of warning service? E.g. sshd has a well known serious leak, you should shut it down for the next few days.

Re: Help! File permissions keep changing...

2004-02-19 Thread Russell Coker
On Thu, 19 Feb 2004 09:12, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread Adam ENDRODI
On Thu, Feb 19, 2004 at 10:37:50AM +0100, m wrote: Control, I mean as doing proxy arp only for special IP's not for all, or etc.. I do not have any idea :( This is more important from day to day for me :( I have some hakers;) in my networks who trying to spoof another computers, If I turn

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited disclosure and no disclosure at all. No vendor currently offers what once was

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary).

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: But the dominance of the CERT is excactly the point I'm criticising. CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't believe in money don't support CERT/CC either because CERT/CC is

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods of time. begone, troll Casting a spell on

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie: Jan Lühr wrote: Well, of course you might have quite good reasons for doing so, but for me, this is quite a good reason for changing the distri or os. But to what? Currently, you have two choices: delayed, limited

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings, Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie: Jan Lühr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings, Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie: Jan Lühr wrote: But the dominance of the CERT is excactly the point I'm criticising. CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,. Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for extended periods

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jose Alberto Guzman wrote: It may be better to set a deadline for the disclosure, instead of a coordinated disclosure. A deadline is some form of coordination, although a rather unidirectional one. 8-) Often, more flexibility is desirable. OTOH, it may also help to coordinate the actual

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: CERT/CC is no longer dominant. Many people now disclose their findings to other coordinators and get paid for that service. Those who don't believe in money don't support CERT/CC either because CERT/CC is selling the information they collect via the Internet Security

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Florian Weimer
Jan Lühr wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use 'em today. Probably yes. If the costs for software production were one or

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greeting,. Am Donnerstag, 19. Februar 2004 15:12 schrieb Florian Weimer: Jan Lühr wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). well, this might be a reason for using computers in situations we use

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Michael Stone
On Thu, Feb 19, 2004 at 02:22:19PM +0100, Florian Weimer wrote: There's an implicit contract among GNU/Linux distributors: you wait with disclosure until most parties are ready. Red Hat rushed ahead several times and the company still has early access to information. Red Hat screwed up a few

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread Jose Alberto Guzman
m wrote: Hello, Another question : it is possible to control arp protocol packets by kernel ? ... if so - this will solve some of problems. But how control arps? perhaps on firewall ? kern 2.4.24/grsec/... You can adjust the refresh timer by setting /proc/sys/net/ipv4/neigh/*/gc_stale_time,

Re: arpwatch and arp packets ...urgent

2004-02-19 Thread m
Hello, JAG MAC addresses can be easily changed (spoofed) with ifconfig's hw JAG option. So they can't be trusted. Better look into ipsec if you really JAG care about authenticity, plus you get pretty good encryption with it as JAG well. of course, I know about them, thanks :) But I want to

Carzy braagins on xnaax

2004-02-19 Thread Mcnamara
eagle relaxation leaden madras meson mitosis quadrant congratulatory salaam transferred flatulent statesmen credential biota horoscope banister tampon edit superb biochemic legacy polemic cavern ,euridyce yea broomcorn kinesic acquisitive invidious bridegroom stipulate

2.2 Kernel Fix

2004-02-19 Thread John Darrington
Are we going to see a patch for the recent mremap() problem for the 2.2 series of kernels, sincee they're apparently vulnerable too? J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://wwwkeys.pgp.net or any PGP keyserver for

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 02:30:54PM +0100, Florian Weimer wrote: Bernd S. Brentrup wrote: On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote: On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote: Yes, this is the norm. Debian hides security bugs from its users for

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: Jan L?hr wrote: But if knowlegde about this vuln is availeable - if fixes are done, but not avaible yet, how do I protect myself? You don't. Tough luck, of course, but that's the price for running affordable,

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread s. keeling
Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary). You seem to imply that one is better off with a proprietary software

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread John Galt
On Wed, 18 Feb 2004, Michael Stone wrote: On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote: May I ask you what local / remote root exploit-fixes are you holding back currently? no. we won't hide problems my tired ass. -- The Internet must be a medium for it is neither Rare nor Well

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Matt Zimmerman
On Thu, Feb 19, 2004 at 09:12:42PM -0700, s. keeling wrote: Incoming from Matt Zimmerman: On Thu, Feb 19, 2004 at 02:24:42PM +0100, Florian Weimer wrote: You don't. Tough luck, of course, but that's the price for running affordable, off-the-shelf software (free or proprietary).