Re: We need a maintained-by-TU chrome/chromium... (Juan Diego)
There are enough arch user maintained repo's, you could ask them to package
it beside that how much work is AUR ;)
2009/11/18 arch-general-requ...@archlinux.org
Send arch-general mailing list submissions to
arch-general@archlinux.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.archlinux.org/mailman/listinfo/arch-general
or, via email, send a message with subject or body 'help' to
arch-general-requ...@archlinux.org
You can reach the person managing the list at
arch-general-ow...@archlinux.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of arch-general digest...
Today's Topics:
1. Re: MUA (Alexandr Bashmakov)
2. Re: pam settings INSECURE (bender02)
3. Re: pam settings INSECURE (Xavier)
4. Re: pam settings INSECURE (bender02)
5. Re: pam settings INSECURE (Jan de Groot)
6. We need a maintained-by-TU chrome/chromium... (Hamo)
7. Re: pam settings INSECURE (Xavier)
8. Re: We need a maintained-by-TU chrome/chromium... (Daenyth Blank)
9. Re: We need a maintained-by-TU chrome/chromium... (Juan Diego)
--
Message: 1
Date: Wed, 18 Nov 2009 17:26:04 +0700
From: Alexandr Bashmakov alex.teor...@gmail.com
Subject: Re: [arch-general] MUA
To: General Discusson about Arch Linux arch-general@archlinux.org
Message-ID:
7d16d2700911180226q14e0d1bbtf1ad3095687a3...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
http://notmuchmail.org/
--
Message: 2
Date: Wed, 18 Nov 2009 12:58:46 +0100
From: bender02 bende...@archlinux.us
Subject: Re: [arch-general] pam settings INSECURE
To: General Discusson about Arch Linux arch-general@archlinux.org
Message-ID:
6eefa5460911180358n14f3937esc3a3dea388c09...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
2009/11/18 Ng Oon-Ee ngoo...@gmail.com:
The *disadvantage* is that the devs/maintainers have to patch up-stream.
This should be kept to a minimum, primarily to reduce their workload,
and also because it is ASSUMED that if you use Arch, you're capable of
doing the Right Thing (tm) according to your situation, or at least
finding out how to.
If you would take the time to look at the packages that are involved
in this (namely shadow and kdebase-workspace), you'd see that both
/etc/pam.d/login and /etc/pam.d/kde are manually suplied alongside the
PKGBUILDs. So in this case, it's not patching but straight
replacing the upstream.
--
Message: 3
Date: Wed, 18 Nov 2009 14:07:39 +0100
From: Xavier shinin...@gmail.com
Subject: Re: [arch-general] pam settings INSECURE
To: General Discusson about Arch Linux arch-general@archlinux.org
Message-ID:
91752840911180507l43f7899ncea46da9f73e2...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Nov 18, 2009 at 6:40 AM, Caleb Cushing xenoterrac...@gmail.com
wrote:
so here's the problem I've discovered
http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-kdm.html
links to arch bug included posting here because I believe both kde's
and arch's developers responses are less than satisfactory. This is a
security bug an easy to fix without making users lives more difficult.
so I'm starting with /etc/pam.d/login
auth ? ? ? ?required ? ?pam_shells.so #add this: why let someone login
who has an invalid shells.
/etc/pam.d/kdm # I'm pretty sure it should be 99% the same as login
since it allows logins.
#%PAM-1.0
auth ? ? ? ?requisite ? pam_nologin.so
auth ? ? ? ?required ? ?pam_unix.so nullok
auth ? ? ? ?required ? ?pam_shells.so # as my blog says setting an
invalid shell is a common way of disabling accounts.
auth ? ? ? ?required ? ?pam_tally.so onerr=succeed file=/var/log/faillog
# use this to lockout accounts for 10 minutes after 3 failed attempts
#auth ? ? ? required ? ?pam_tally.so deny=2 unlock_time=600 onerr=succeed
file=/
account ? ? required ? ?pam_access.so
account ? ? required ? ?pam_time.so
account ? ? required ? ?pam_unix.so
password ? ?required ? ?pam_unix.so
#password ? required ? ?pam_cracklib.so difok=2 minlen=8 dcredit=2
ocredit=2 ret
#password ? required ? ?pam_unix.so md5 shadow use_authtok
session ? ? required ? ?pam_unix.so
session ? ? required ? ?pam_env.so
session ? ? required ? ?pam_limits.so
also I believe pam_tally2 replaces pam_tally may wish to consider
migrating (non urgent next release?)
So basically you just need to add authrequired
pam_shells.so to all pam files related to login, correct ?
Or what were the other problematic settings of pam.d/kde ?
The comments about this being an upstream problem are invalid, as
these pam files are all shipped by arch :