Previously eim wrote:
> Which Finger daemon is *really* secure ?
I haven't looked at all of them, but cfingerd most certainly is not.
Wichet.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROT
Previously P Prince wrote:
> The eaisest and most failsafe way to secure bind is to install djbdns.
And the simple answer to that is:
1. bind is not DFSG-free and not packaged for Debian which makes it
off-topic here.
2. replacing bind is not the same thing as securing it, which was
the ques
Previously P Prince wrote:
> The eaisest and most failsafe way to secure bind is to install djbdns.
And the simple answer to that is:
1. bind is not DFSG-free and not packaged for Debian which makes it
off-topic here.
2. replacing bind is not the same thing as securing it, which was
the que
Previously Thomas Bushnell, BSG wrote:
> Posix requires a /tmp directory which arbitrary programs can write to,
> and Posix knows nothing of noexec; a valid program of any sort could
> well decide to use that feature, and Debian shouldn't bother trying to
> work around it, IMHO.
On the other, it's
Previously Thomas Bushnell, BSG wrote:
> What sort of insecure cgi script are you thinking of?
Trivial protection against stupid rootkits.
> In any case, it's part of the normal conventions of all Unix-based
> systems that /tmp is accessible to every user, for writing files and
> for executing th
Previously Ian wrote:
> I've noticed some perl packages trying to exec config files from /tmp
It's a known bug in debconf.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]
Previously Thomas Bushnell, BSG wrote:
> Posix requires a /tmp directory which arbitrary programs can write to,
> and Posix knows nothing of noexec; a valid program of any sort could
> well decide to use that feature, and Debian shouldn't bother trying to
> work around it, IMHO.
On the other, it'
Previously Thomas Bushnell, BSG wrote:
> What sort of insecure cgi script are you thinking of?
Trivial protection against stupid rootkits.
> In any case, it's part of the normal conventions of all Unix-based
> systems that /tmp is accessible to every user, for writing files and
> for executing t
Previously Ian wrote:
> I've noticed some perl packages trying to exec config files from /tmp
It's a known bug in debconf.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]
Previously Hendrik Naumann wrote:
> All or just those that are not signed correctly?
All, since none are signed currently. If we only use signatures
from developers the debsig policy would also be huge since you
would need to list 500+ keys in it and update it regularly.
> Is there the possibilit
Previously Hendrik Naumann wrote:
> All or just those that are not signed correctly?
All, since none are signed currently. If we only use signatures
from developers the debsig policy would also be huge since you
would need to list 500+ keys in it and update it regularly.
> Is there the possibili
Previously Jean-Marc Boursot wrote:
> Like the last postfix DoS? Am I wrong or there wasn't any bugtraq
> report for that?
There was.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PR
Previously Jean-Marc Boursot wrote:
> Like the last postfix DoS? Am I wrong or there wasn't any bugtraq
> report for that?
There was.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PR
Previously Torrin wrote:
> Well, if it's not used (skipped) should we even bother installing
> debsig-verify and debsigs?
Right now it's only useful if you want to play with the technology.
Wichert.
--
_
/[EMAIL PROTECTED]
Previously Torrin wrote:
> Well, if it's not used (skipped) should we even bother installing
> debsig-verify and debsigs?
Right now it's only useful if you want to play with the technology.
Wichert.
--
_
[EMAIL PROTECTED]
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> Should I do it?
Talk to Josip Rodin, he is currently responsible for doing this.
Personally I would love to see somebody else working on it as well.
> This means changing the current .data files and changing
> the way they are published so the BI
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> A note for the Security Team: please add a new tag to the DSA's data:
> and that would make it easier to
Half the time we can't do that because we can't register a tag since
the information can't be released yet. We could add them at a later
dat
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> Should I do it?
Talk to Josip Rodin, he is currently responsible for doing this.
Personally I would love to see somebody else working on it as well.
> This means changing the current .data files and changing
> the way they are published so the B
(Please don't use overly long lines, it makes text hard to read).
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> A far better scheme was the one proposed by Wichert (signing
> only one file: Packages.gz and stablish a trust relationship
> like this):
FWIW, I didn't propose it I just described
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> A note for the Security Team: please add a new tag to the DSA's data:
> and that would make it easier to
Half the time we can't do that because we can't register a tag since
the information can't be released yet. We could add them at a later
da
(Please don't use overly long lines, it makes text hard to read).
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> A far better scheme was the one proposed by Wichert (signing
> only one file: Packages.gz and stablish a trust relationship
> like this):
FWIW, I didn't propose it I just describe
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> I guess a public database could be useful both for
We have a private database (well, a status-file in which we keep track
of things). A public database can't be used since we frequently get
private info we can't share.
Wichert.
--
_
Previously J C Lawrence wrote:
> What is the status of having Jack Goerzen's dpkg patch accepted?
>
> http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html
A modified version of that was commited to CVS om March 9.
Wichert.
--
___
Previously Blake Barnett wrote:
> Conectiva currently has support for signed _repositories_, as well as
> signed RPM packages. Check out their /etc/apt/sources.list for more
> info on it.
That's exactly what I just described.. the Conectiva apt also seems
to be based on an ancient version, they
Previously Javier Fern?ndez-Sanguino Pe?a wrote:
> I guess a public database could be useful both for
We have a private database (well, a status-file in which we keep track
of things). A public database can't be used since we frequently get
private info we can't share.
Wichert.
--
Previously J C Lawrence wrote:
> What is the status of having Jack Goerzen's dpkg patch accepted?
>
> http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html
A modified version of that was commited to CVS om March 9.
Wichert.
--
__
Previously jereme wrote:
> Can/is the checking of these signatures, (and fetching the appropriate
> developer keys) integrated into apt-get? What am I missing?
Apt works at a different level: it deals with download packages and
archives, so it will not verify the signature that is embedded in
a d
Previously Emiel Metselaar wrote:
> Could anyone point me to some documentation about how this fits within
> the 'usual' apt-get update apt-get install procedure.
The idea is:
* packages are signed using debsig and get one (or more) embedded
signatures
* apt & friends don't look at the signatur
Previously ralphtheraccoon wrote:
> There isn't a "stable" debsig-verify or other package...
> does this mean that "stable" is less secure than "unstable"?
Neither actually, the debsig infrastructure isn't use currently
Wichert.
--
_
Previously Alan James wrote:
> don't you mean debsig-verify ?
Hmm, possibly :)
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 10
Previously Blake Barnett wrote:
> Conectiva currently has support for signed _repositories_, as well as
> signed RPM packages. Check out their /etc/apt/sources.list for more
> info on it.
That's exactly what I just described.. the Conectiva apt also seems
to be based on an ancient version, the
Previously Alexander Karelas wrote:
> RedHat uses a PGP signature scheme. What are we doing about it?
apt-get install debsign
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]
Previously jereme wrote:
> Can/is the checking of these signatures, (and fetching the appropriate
> developer keys) integrated into apt-get? What am I missing?
Apt works at a different level: it deals with download packages and
archives, so it will not verify the signature that is embedded in
a
Previously Emiel Metselaar wrote:
> Could anyone point me to some documentation about how this fits within
> the 'usual' apt-get update apt-get install procedure.
The idea is:
* packages are signed using debsig and get one (or more) embedded
signatures
* apt & friends don't look at the signatu
Previously ralphtheraccoon wrote:
> There isn't a "stable" debsig-verify or other package...
> does this mean that "stable" is less secure than "unstable"?
Neither actually, the debsig infrastructure isn't use currently
Wichert.
--
Previously Alan James wrote:
> don't you mean debsig-verify ?
Hmm, possibly :)
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 10
Previously Alexander Karelas wrote:
> RedHat uses a PGP signature scheme. What are we doing about it?
apt-get install debsign
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]
Previously Ade Talabi wrote:
> Hey! why are u guys always arguing
It leads to better solutions :)
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.li
Previously Gergely Trifonov wrote:
> it's okay if you just remove the setuid bit from /bin/ping (chmod -s
> /bin/ping), so users won't be able to run it
That doesn't solve the real problem, which is not the fact that the
user runs ping but that he can run too many processes starving
machinen reso
Previously Halil Demirezen wrote:
> How can i solve the problem that after i ping my computer(server) with
> "ping localhost&" for about 160 times, the system starts not to give
> response and the load average of the cpu raises to the %81.
Look at the PAM limits documentation.
Wichert.
--
___
Previously Ade Talabi wrote:
> Hey! why are u guys always arguing
It leads to better solutions :)
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.li
Previously Gergely Trifonov wrote:
> it's okay if you just remove the setuid bit from /bin/ping (chmod -s
> /bin/ping), so users won't be able to run it
That doesn't solve the real problem, which is not the fact that the
user runs ping but that he can run too many processes starving
machinen res
Previously Halil Demirezen wrote:
> How can i solve the problem that after i ping my computer(server) with
> "ping localhost&" for about 160 times, the system starts not to give
> response and the load average of the cpu raises to the %81.
Look at the PAM limits documentation.
Wichert.
--
__
Previously martin f krafft wrote:
> because it's filtering based on the IP information. brides speak no
> IP.
It filters based on packet content that just happens to be IP
information. Just like the u32 filter, except the syntax is easier.
It still bridges.
Wichert.
--
___
Previously martin f krafft wrote:
> because it's filtering based on the IP information. brides speak no
> IP.
It filters based on packet content that just happens to be IP
information. Just like the u32 filter, except the syntax is easier.
It still bridges.
Wichert.
--
__
Previously martin f krafft wrote:
> oh my, everyone is misunderstanding my non-important, trivial point. i
> am not doubting that linux bridging and netfilter do interface, i am
> merely saying that such a fusion is not a bridge anymore.
Why is a filtering bridge no longer a bridge? It does not ro
Previously martin f krafft wrote:
> oh my, everyone is misunderstanding my non-important, trivial point. i
> am not doubting that linux bridging and netfilter do interface, i am
> merely saying that such a fusion is not a bridge anymore.
Why is a filtering bridge no longer a bridge? It does not r
Previously Howland, Curtis wrote:
> Excuse me if this is old hat, has anyone else heard of a vulnerability
> like this?
It sounds strange. The Linux kernel does not do seperate caching for
NFS as far as I know, and all caching is done in kernel space which
you can not see from userspace (unless yo
Previously Ted Cabeen wrote:
> However, thinking about it, this doesn't work. If you're editing as root, you
> can use :e to switch to editing a SUID root file (any one you can write to
> will work), delete the entire contents, and then use :r to bring in the
> /bin/sh executable.
But you can re
Previously martin f krafft wrote:
> okay, this is an interesting point. however, all i was saying is that
> the linux bridging project is commiting suicide (as the bridging
> project) as soon as they interface with netfilter or anything else
> that works with IP.
Wrong :). Someone (forgot his name
Previously John DOE wrote:
> PS : Thanks a lot for your help. I don't know how familiar you are
> with cryptographic concepts but I already have the original sheets of
> SSL from Netscape and SSL is not a bilateral entity authentication,
> identification protocol you only know that the server at th
Previously Howland, Curtis wrote:
> Excuse me if this is old hat, has anyone else heard of a vulnerability
> like this?
It sounds strange. The Linux kernel does not do seperate caching for
NFS as far as I know, and all caching is done in kernel space which
you can not see from userspace (unless y
Previously Ted Cabeen wrote:
> However, thinking about it, this doesn't work. If you're editing as root, you
> can use :e to switch to editing a SUID root file (any one you can write to
> will work), delete the entire contents, and then use :r to bring in the
> /bin/sh executable.
But you can r
Previously martin f krafft wrote:
> okay, this is an interesting point. however, all i was saying is that
> the linux bridging project is commiting suicide (as the bridging
> project) as soon as they interface with netfilter or anything else
> that works with IP.
Wrong :). Someone (forgot his nam
Previously John DOE wrote:
> PS : Thanks a lot for your help. I don't know how familiar you are
> with cryptographic concepts but I already have the original sheets of
> SSL from Netscape and SSL is not a bilateral entity authentication,
> identification protocol you only know that the server at t
Previously martin f krafft wrote:
> nope, this isn't possible with the current sshd. an interesting
> feature though...
>From the sshd manpage:
AllowUsers
This keyword can be followed by a list of user names, separated
by spaces. If specified, login is allowed only
Previously martin f krafft wrote:
> nope, this isn't possible with the current sshd. an interesting
> feature though...
>From the sshd manpage:
AllowUsers
This keyword can be followed by a list of user names, separated
by spaces. If specified, login is allowed onl
Previously Ed Street wrote:
> Any input/thoughts on this?
Just that it's always amusing to watch a scriptkiddie try to hack your
box and see them fail.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occup
Previously Ed Street wrote:
> Any input/thoughts on this?
Just that it's always amusing to watch a scriptkiddie try to hack your
box and see them fail.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occup
Previously Guillaume Morin wrote:
> gzip runs with user privileges, therefore this is not a security
> problem.
But a fair amount of privileged programs do run gzip so it can be
a security problem.
Wichert.
--
_
/[EMAIL PROTECT
Previously Vineet Kumar wrote:
> So are "please" and "thank you," but it's generally considered polite.
Also using Mail-Followup-To is standard and expected behaviour on
debian lists.
Wichert.
--
_
/[EMAIL PROTECTED] T
Previously Guillaume Morin wrote:
> gzip runs with user privileges, therefore this is not a security
> problem.
But a fair amount of privileged programs do run gzip so it can be
a security problem.
Wichert.
--
_
[EMAIL PROTECT
Previously Vineet Kumar wrote:
> So are "please" and "thank you," but it's generally considered polite.
Also using Mail-Followup-To is standard and expected behaviour on
debian lists.
Wichert.
--
_
[EMAIL PROTECTED] T
Previously Wade Richards wrote:
> But I'm also lazy. I'm not going to spend hours or weeks writing code to
> install a tty sniffer, find enough disk space for the logs, and search
> through the log files for something interesting. I'm a nozy root,
> I'm not a masochistic root.
No, you're just la
Previously Wade Richards wrote:
> But I'm also lazy. I'm not going to spend hours or weeks writing code to
> install a tty sniffer, find enough disk space for the logs, and search
> through the log files for something interesting. I'm a nozy root,
> I'm not a masochistic root.
No, you're just l
Previously Howland, Curtis wrote:
> I have a remote server that I do not trust myself to upgrade from
> Potato(e) to Woody, and such vulnerabilities do worry me a little. Is
> there any general expectation that such "back porting" will continue
> once Woody is released?
I expect only for a limited
Previously Howland, Curtis wrote:
> I have a remote server that I do not trust myself to upgrade from
> Potato(e) to Woody, and such vulnerabilities do worry me a little. Is
> there any general expectation that such "back porting" will continue
> once Woody is released?
I expect only for a limite
Previously Ethan Benson wrote:
> why don't you bother to read what i said. script kiddies don't exploit
> unknown holes as you have stated, and what i stated above is i don't
> leave KNOWN PATCHED holes on my boxes, those are what script kiddies
> attack.
Script kiddies can get their hand on 0-day
Previously Ethan Benson wrote:
> why don't you bother to read what i said. script kiddies don't exploit
> unknown holes as you have stated, and what i stated above is i don't
> leave KNOWN PATCHED holes on my boxes, those are what script kiddies
> attack.
Script kiddies can get their hand on 0-da
Previously Ethan Benson wrote:
> sorry i don't leave known security holes wide open on my boxes. only
> an idiot does that.
If you think your box does not have currently unknown holes you are
naive :)
Wichert.
--
_
/[EMAIL PROT
Previously Rolf Kutz wrote:
> If you have a linux-fileserver serving binaries for
> linux-workstations, how should it tell?
It won't have any effect then anyway.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally
Previously Ethan Benson wrote:
> sorry i don't leave known security holes wide open on my boxes. only
> an idiot does that.
If you think your box does not have currently unknown holes you are
naive :)
Wichert.
--
_
[EMAIL PROT
Previously Rolf Kutz wrote:
> If you have a linux-fileserver serving binaries for
> linux-workstations, how should it tell?
It won't have any effect then anyway.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally
Previously Lars Bjarby wrote:
> While were on the subject, is there an OpenSSH port of SFTP?
openssh has a sftp subsystem, yes.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED
Previously Rolf Kutz wrote:
> If you mount partitions of a different OS or
> machine, whose programs can't or shouldn't be
> executed.
Any sane OS will gave a sane error when you do that anyway.
Wichert.
--
_
/[EMAIL PROTECTED]
Previously Lars Bjarby wrote:
> While were on the subject, is there an OpenSSH port of SFTP?
openssh has a sftp subsystem, yes.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED
Previously Rolf Kutz wrote:
> If you mount partitions of a different OS or
> machine, whose programs can't or shouldn't be
> executed.
Any sane OS will gave a sane error when you do that anyway.
Wichert.
--
_
[EMAIL PROTECTED]
Previously Ethan Benson wrote:
> 1: if your system is vulnerable to script kiddies then admin needs to
>be taken out back and beaten with a large LART.
Sure, but I don't mind having a hopefully completely redundant extra
layer in there.
> 2: if the script kiddie even has 2 tenths of a percent
Previously Emmanuel Lacour wrote:
> What's the use of noexec flag???
Historic thing mostly with very little practical use these days.
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PRO
Previously Ethan Benson wrote:
> its not, it provides you NO extra security whatsoever, and will break
> many many things.
It breaks a fair number of scripts that script-kiddies use, and as
such it is somewhat useful.
Wichert.
--
___
Previously Emmanuel Lacour wrote:
> Is this due to debconf or to the scripts preinst from ntpdate??
You hit bug# 116448 (see http://bugs.debian.org/116448)
Wichert.
--
_
/[EMAIL PROTECTED] This space intentionally left
Previously Ethan Benson wrote:
> 1: if your system is vulnerable to script kiddies then admin needs to
>be taken out back and beaten with a large LART.
Sure, but I don't mind having a hopefully completely redundant extra
layer in there.
> 2: if the script kiddie even has 2 tenths of a percen
Previously Emmanuel Lacour wrote:
> What's the use of noexec flag???
Historic thing mostly with very little practical use these days.
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PRO
Previously Ethan Benson wrote:
> its not, it provides you NO extra security whatsoever, and will break
> many many things.
It breaks a fair number of scripts that script-kiddies use, and as
such it is somewhat useful.
Wichert.
--
__
Previously Emmanuel Lacour wrote:
> Is this due to debconf or to the scripts preinst from ntpdate??
You hit bug# 116448 (see http://bugs.debian.org/116448)
Wichert.
--
_
[EMAIL PROTECTED] This space intentionally left
Previously Ville Uski wrote:
> Thanks for info. Yes, I have that line in my sources.list, and I also
> believe I am fine. Our network admin used the nessus ssh plugin to scan
> the network. He only says that nessus gives a warning about my computer
> (concerning the crc bug) and knows nothing more
Previously Ville Uski wrote:
> Thanks for info. Yes, I have that line in my sources.list, and I also
> believe I am fine. Our network admin used the nessus ssh plugin to scan
> the network. He only says that nessus gives a warning about my computer
> (concerning the crc bug) and knows nothing mor
Previously Marcel Welschbillig wrote:
> I know it works on the standard kernel but every time i compile my own
> kernel i lose the ability to do this.
Enable IP aliasing.
Wichert.
--
_
/ Nothing is fool-proof to a suffici
Previously Marcel Welschbillig wrote:
> I know it works on the standard kernel but every time i compile my own
> kernel i lose the ability to do this.
Enable IP aliasing.
Wichert.
--
_
/ Nothing is fool-proof to a suffic
Previously Tom Breza wrote:
> No I don't have a snort in the system
> Any other sugestions?
Can't think of anything. Check the email timings to see if the
correspond to a crontab maybe.
Wichert.
--
_
/ Nothing is fool-proo
Previously Tom Breza wrote:
> Hi I got this today in my mail box, this is generated by somthing but I
> don't know what is it? Why I got message from root? and why is empty?
Do you have snort installed?
Wichert.
--
_
/ Not
Previously Tom Breza wrote:
> No I don't have a snort in the system
> Any other sugestions?
Can't think of anything. Check the email timings to see if the
correspond to a crontab maybe.
Wichert.
--
_
/ Nothing is fool-pro
Previously Tom Breza wrote:
> Hi I got this today in my mail box, this is generated by somthing but I
> don't know what is it? Why I got message from root? and why is empty?
Do you have snort installed?
Wichert.
--
_
/ No
Previously Tim Haynes wrote:
> Any pointers what to do to fix it?
man ssh and look for HostKeyAlias.
Wichert.
--
_
/ Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED] http://
Previously Tim Haynes wrote:
> Any pointers what to do to fix it?
man ssh and look for HostKeyAlias.
Wichert.
--
_
/ Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED] http:/
Previously Charl Matthee wrote:
> An easier way to get things going may be to use cbq.init
> [http://freshmeat.net/projects/cbq.init/].
Or tcng.sf.net, but definitely read the howto at http://ds9a.nl/
Wichert.
--
_
/ Nothi
Previously Charl Matthee wrote:
> An easier way to get things going may be to use cbq.init
> [http://freshmeat.net/projects/cbq.init/].
Or tcng.sf.net, but definitely read the howto at http://ds9a.nl/
Wichert.
--
_
/ Noth
Previously Martin Fluch wrote:
> I'm running unstable and (maybe) a month ago I spoted a fish swiming over
> my desktop from left to right, just a small one, just once. Today again.
I suspect you hit an easter egg in GNOME.
Wichert.
--
_
Previously Martin Fluch wrote:
> I'm running unstable and (maybe) a month ago I spoted a fish swiming over
> my desktop from left to right, just a small one, just once. Today again.
I suspect you hit an easter egg in GNOME.
Wichert.
--
For amusement I checked the web logs for a few debian machines to see
if they had some red worm attempts. Seems we've been probed a fair
bit: 16 times on www.spi-inc.org, 22 on non-us.debian.org and 18
on www.debian.org. Almost all attempts were made on July 19. Aren't
we glad we all run Linux? :)
101 - 200 of 312 matches
Mail list logo
