Re: qmail ERR- authorization
[EMAIL PROTECTED] wrote: : I have problem with authorization qmail pop3 clients. I don't know why : qmail-pop3 not authorize my users on all accounts. When we use client from Did you run the tests on checkpasswd as described in its README? http://cr.yp.to/checkpwd/install.html Simulate a successful POP login, using a correct account name and password instead of Frodo and Friend. You should see the account's home directory. -- Stephen Cope - http://sdc.org.nz/ PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On Wed, Oct 24, 2001 at 10:17:13PM +0200, Patrice Neff wrote: > > I believe this would not be reasonable for the Debian distribution, > but you could create a customized and secure Debian version where you > do a source code audit before accepting any package. Or maybe it could > be done with another APT tree? > > well, just my 2 cents > patrice > Many operating systems have a "limited" version which is considered more secure and is targeted towards certification. Take, for exmaple, Trusted Solaris... Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does Debian need to enforce a better Security policy for packages?
On Tue, Oct 23, 2001 at 10:28:02PM +0800, Michael Robinson wrote: > > FreeBSD does it for their ports tree. In fact, this has been a matter of > controversy, as the FreeBSD team issues a huge number of security advisories > for software that really has nothing to do with FreeBSD. This has caused casual > observers to erroneously believe FreeBSD is less secure than other less > carefully managed operating system projects. Yes, you can get the same impression from Debian by checking bugtraq's vulnerability database. You can never know if security issues arise due to a) security conscious people checking stuff b) security unconscious people ignoring it. > > Yes, source-code audits are time-consuming. Time-consuming is different > from "not possible", however. The alternative is the "ostrich" method of > security management. > Not that I can spare time to offer myself, but didn't a group of people show up some interest in starting a code audit for Debian (starting with the base packages). In any case, Debian does benefit from other code audits (take the kernel for example)... Regards Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does Debian need to enforce a better Security policy for packages?
On Wed, Oct 24, 2001 at 10:19:59AM +0200, Christian Kurz wrote: > On 23/10/01, Michael Robinson wrote: > > On Tue, Oct 23, 2001 at 09:55:04AM +0200, Christian Kurz wrote: > > > Do you know how difficult and time-consuming it really is to do a manual > > > source code audit? Also the available programs for source code audits > > > can only give you hints which parts of a program might be suspicious, but > > > you still would have to verify everything by hand to be really sure. > > > FreeBSD does it for their ports tree. In fact, this has been a matter of > > Does what? Just look for some suspicous functions or code-fragments or > do a full audiit for the whole source? The FreeBSD approach is to start at the most dangerous end (common SUID root executables, obvious buffer overflows, etc.) and work towards the least dangerous end (e.g. race conditions in obscure non-SUID applications) as time and resources permit. It's a "best effort" approach. There's no guarantee of catching every bug, but there's a reasonable assurance that most users aren't exposed to glaring vulnerabilities in the most common installations. You can go through the BugTraq archives looking for "FreeBSD Ports" announcements to see the kind of vulnerabilities the FreeBSD team has been protecting their users from so far. -Michael Robinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux 2.2r3 vulnerabilities ?
Hi, On Thu, 25 Oct 2001, Petre Daniel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: MD5 > > Heya, > I run a potato at home and i will set the computer at work > with potato as well.Since that will be a 24h internet connected > pc,i am wondering what are the 2.2 release 3 vulnerabilities for > the sistem installed from the cds without any online update. > Is the ssh package in potato vulnerable? > I'd appreciate it if you can give me some urls. > thx, > Dani, > hackers unsupport. > add security lines for apt as suggested before and if the box is going to work as a firewall of some kind upgrade to kernel 2.4 to use iptables (and install modutils-2.4!). Greetz, Sebastiaan -- NT is the OS of the future. The main engine is the 16-bit Subsystem (also called MS-DOS Subsystem). Above that, there is the windoze 95/98 16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a *real* 32-bit system.
Re: qmail ERR- authorization
[EMAIL PROTECTED] wrote: : I have problem with authorization qmail pop3 clients. I don't know why : qmail-pop3 not authorize my users on all accounts. When we use client from Did you run the tests on checkpasswd as described in its README? http://cr.yp.to/checkpwd/install.html Simulate a successful POP login, using a correct account name and password instead of Frodo and Friend. You should see the account's home directory. -- Stephen Cope - http://sdc.org.nz/ pgptrg0KcJU3E.pgp Description: PGP signature
Re: Does Debian need to enforce a better Security policy for packages?
On Wed, Oct 24, 2001 at 10:17:13PM +0200, Patrice Neff wrote: > > I believe this would not be reasonable for the Debian distribution, > but you could create a customized and secure Debian version where you > do a source code audit before accepting any package. Or maybe it could > be done with another APT tree? > > well, just my 2 cents > patrice > Many operating systems have a "limited" version which is considered more secure and is targeted towards certification. Take, for exmaple, Trusted Solaris... Regards Javi
Re: Does Debian need to enforce a better Security policy for packages?
On Tue, Oct 23, 2001 at 10:28:02PM +0800, Michael Robinson wrote: > > FreeBSD does it for their ports tree. In fact, this has been a matter of > controversy, as the FreeBSD team issues a huge number of security advisories > for software that really has nothing to do with FreeBSD. This has caused > casual > observers to erroneously believe FreeBSD is less secure than other less > carefully managed operating system projects. Yes, you can get the same impression from Debian by checking bugtraq's vulnerability database. You can never know if security issues arise due to a) security conscious people checking stuff b) security unconscious people ignoring it. > > Yes, source-code audits are time-consuming. Time-consuming is different > from "not possible", however. The alternative is the "ostrich" method of > security management. > Not that I can spare time to offer myself, but didn't a group of people show up some interest in starting a code audit for Debian (starting with the base packages). In any case, Debian does benefit from other code audits (take the kernel for example)... Regards Javi
Re: Does Debian need to enforce a better Security policy for packages?
On Wed, Oct 24, 2001 at 10:19:59AM +0200, Christian Kurz wrote: > On 23/10/01, Michael Robinson wrote: > > On Tue, Oct 23, 2001 at 09:55:04AM +0200, Christian Kurz wrote: > > > Do you know how difficult and time-consuming it really is to do a manual > > > source code audit? Also the available programs for source code audits > > > can only give you hints which parts of a program might be suspicious, but > > > you still would have to verify everything by hand to be really sure. > > > FreeBSD does it for their ports tree. In fact, this has been a matter of > > Does what? Just look for some suspicous functions or code-fragments or > do a full audiit for the whole source? The FreeBSD approach is to start at the most dangerous end (common SUID root executables, obvious buffer overflows, etc.) and work towards the least dangerous end (e.g. race conditions in obscure non-SUID applications) as time and resources permit. It's a "best effort" approach. There's no guarantee of catching every bug, but there's a reasonable assurance that most users aren't exposed to glaring vulnerabilities in the most common installations. You can go through the BugTraq archives looking for "FreeBSD Ports" announcements to see the kind of vulnerabilities the FreeBSD team has been protecting their users from so far. -Michael Robinson
Unidentified subject!
unsubscribe
