My name is 2Lt Arthur Martins,I'M US Army in Afghanistan (Kabul). I want you to
keep my Consignment of funds safe for me but the question is can you be
trusted?. Please if you are interested kindly Email me at
arthurmartins...@yahoo.co.nz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lis
# Automatically generated email from bts, devscripts version 2.10.35
# closed for comments :P
archive 311772
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A. Dreyer un jour écrivit:
On Thu, 28 Aug 2008, Johan Walles wrote:
Anyway root already has the capability to view passwords
(i.e. by installing alternate login programs, sniffing tty, ...)
That's obviously true, but that doesn't cover the case when logs are
copied to a second system with
Hi,
It is not often that I post but
1) Logging invalid usernames which can be used to detect all manor of
attacks including dictionary username attacks and password brute force
attacks.
2) As pointed out earlier the file is root only access. The argument
that can be read if you physical ac
On Thu, Aug 28, 2008 at 02:37:37PM -0700, Steve Langasek wrote:
On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote:
auth.log was invented for this reason, and separated to standard log:
it should be readable only by root,
Then there is a bug in another package if this is what
On Thu, Aug 28, 2008 at 02:37:37PM -0700, Steve Langasek wrote:
> On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote:
> > auth.log was invented for this reason, and separated to standard log:
> > it should be readable only by root,
>
> Then there is a bug in another package if th
Nico Golde un jour écrivit:
Hi Johan,
* Johan Walles <[EMAIL PROTECTED]> [2008-08-28 13:14]:
2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
[...]
So auth.log should log usernames, so that users don't do
wrong assumption that password are not accessible by root!
I can see a point in loggi
On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote:
> auth.log was invented for this reason, and separated to standard log:
> it should be readable only by root,
Then there is a bug in another package if this is what "should" be, because
/var/log/auth.log is readable by group adm
On Thu, Aug 28, 2008 at 08:37:07PM +0200, ,,, wrote:
> Excuse me, but this is very simple thing, this is not big philosophical
> problem.
> The software has ability to log login+password for troubleshooting, which
> is great (users ALWAYS claim that they are writting their password
> correctly,
Excuse me, but this is very simple thing, this is not big philosophical
problem.
The software has ability to log login+password for troubleshooting, which
is great (users ALWAYS claim that they are writting their password
correctly, so this is nice to have). Since it's not enabled by default, yo
On 2008-08-28 13:05, Johan Walles wrote:
> It's readable by anybody with physical access to the hardware.
If their have physical access to the hardware, auth.log would be
my least worry.
> That doesn't mean Debian should *help* root doing that in a default
> install. Security by default, anybody
Mark Brown wrote:
On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote:
2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
auth.log was invented for this reason, and separated to standard log:
it should be readable only by root, because users do errors.
It's readable by anybody wi
On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote:
> 2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> > auth.log was invented for this reason, and separated to standard log:
> > it should be readable only by root, because users do errors.
> It's readable by anybody with physical a
Hi Johan,
* Johan Walles <[EMAIL PROTECTED]> [2008-08-28 13:14]:
> 2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
[...]
> > So auth.log should log usernames, so that users don't do
> > wrong assumption that password are not accessible by root!
>
> I can see a point in logging *valid* usernam
2008/8/28 Giacomo A. Catenazzi <[EMAIL PROTECTED]>:
> Johan Walles wrote:
>> Security shouldn't be based on nobody ever doing more or less common
>> mistakes.
>
> auth.log was invented for this reason, and separated to standard log:
> it should be readable only by root, because users do errors.
It
Hi Johan,
* Johan Walles <[EMAIL PROTECTED]> [2008-08-28 11:46]:
> Let's keep debian-security in the discussion to see what others have
> to say about this.
>
> Technically I agree with you when you say that people shouldn't enter
> anything but their usernames at the login prompt, but the fact is
Johan Walles wrote:
Hi Nico!
Let's keep debian-security in the discussion to see what others have
to say about this.
Technically I agree with you when you say that people shouldn't enter
anything but their usernames at the login prompt, but the fact is that
people (like me and the bug submitter
Hi Nico!
Let's keep debian-security in the discussion to see what others have
to say about this.
Technically I agree with you when you say that people shouldn't enter
anything but their usernames at the login prompt, but the fact is that
people (like me and the bug submitter for example) *do* ent
Hi Johan,
* Johan Walles <[EMAIL PROTECTED]> [2008-08-27 22:26]:
> severity 311772 critical
> tag 311772 + security
> thanks
>
> When users' clear text passwords are logged, that's a security hole.
>
> Setting severity to critical since this bug "introduces a security
> hole on systems where you
# Automatically generated email from bts, devscripts version 2.10.35
severity 311772 normal
# put down the crack pipe
tags 311772 - security
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
severity 311772 critical
tag 311772 + security
thanks
When users' clear text passwords are logged, that's a security hole.
Setting severity to critical since this bug "introduces a security
hole on systems where you install the package". Quote is from the
definition of the critical severity at
h
That's certainly not how it should work
Are you sure you are not using the audit option to pam_unix? Without
that option I see:
Jun 3 13:59:06 cz login[4777]: (pam_unix) check pass; user unknown
Jun 3 13:59:06 cz login[4777]: (pam_unix) authentication failure;
logname=hartmans uid=0 euid=0 tt
22 matches
Mail list logo
