On Sun, 13 Jun 2010 09:58:38 +0200
Thomas Bächler <thomas@archlinux.org> wrote:

> Am 13.06.2010 02:33, schrieb Alexander Duscheleit:
> > OTOH the original mail was meant more to alert *users* of
> > unrealircd, the maintainer should actually already have been
> > noticed via the bug.
>
> In that case, it seems you chose your list wisely.
>
> > On a side-note, Sergej already has published a new pkgrel this
> > afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already
> > obsolete before I wrote it.
>
> Good, didn't notice that. I was quite shocked when I read about the
> issue.
>

This is the reason why we need package signing for Pacman. I'm aware
that some progress has been made and it's being worked on. Are there
any updates?

Ananda

On 13/06/10 19:38, Ananda Samaddar wrote:

On Sun, 13 Jun 2010 09:58:38 +0200
Thomas Bächler<thomas@archlinux.org> wrote:


Am 13.06.2010 02:33, schrieb Alexander Duscheleit:

OTOH the original mail was meant more to alert *users* of
unrealircd, the maintainer should actually already have been
noticed via the bug.


In that case, it seems you chose your list wisely.


On a side-note, Sergej already has published a new pkgrel this
afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already
obsolete before I wrote it.


Good, didn't notice that. I was quite shocked when I read about the
issue.



This is the reason why we need package signing for Pacman. I'm aware
that some progress has been made and it's being worked on. Are there
any updates?



Yes... because package signing magically fixes all upstream issues.

Allan

On Sun, 13 Jun 2010 19:48:53 +1000
Allan McRae <allan@archlinux.org> wrote:

> >>
> >
> > This is the reason why we need package signing for Pacman. I'm
> > aware that some progress has been made and it's being worked on.
> > Are there any updates?
> >
>
> Yes... because package signing magically fixes all upstream issues.
>
> Allan

My point was that malicious attackers can add compromise packages to
mirrors and alter the repo.db. Package signing would mitigate that. I
was attempting to say that what happened in this instance could happen
to an Arch mirror or mirrors. There's no need to be rude.

Ananda

On Sun, 2010-06-13 at 10:48 +0100, Ananda Samaddar wrote:
> On Sun, 13 Jun 2010 19:48:53 +1000
> Allan McRae <allan@archlinux.org> wrote:
>
> > >>
> > >
> > > This is the reason why we need package signing for Pacman. I'm
> > > aware that some progress has been made and it's being worked on.
> > > Are there any updates?
> > >
> >
> > Yes... because package signing magically fixes all upstream issues.
> >
> > Allan
>
> My point was that malicious attackers can add compromise packages to
> mirrors and alter the repo.db. Package signing would mitigate that. I
> was attempting to say that what happened in this instance could happen
> to an Arch mirror or mirrors. There's no need to be rude.
>
Everytime this comes up the response is the same. Package signing will
only be a big deal if enough people are willing to get coding to
implement it. Necessity is determined by availability, not the other way
round.

The way I see it, if noone is willing to work on it, it can't be too
important in a general sense.

On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:

And keep in mind that package signing per se will not solve this kind
of problems. Repository database signing is more important for that
solution, but is a problem in the current workflow of Arch developers.


How exactly is core and extra database populated?

Moreover, instead of building all packages in the private PCs of
developers, I think it is preferable to submit PKGBUILDs to build servers
(via web interface maybe) and let the servers do the build + signing +
repoupdate... That way if a developer's system gets compromised his
packages will stay clean. Of course that needs extra work and equipment,
but perhaps we can agree to it as a future target.


On another note, an easy but maybe a bit costly way to avoid any MITM
tampering to packages, is serve *.md5 files for every package through a
trusted HTTPS host. Then everyone can query that single host and check
if the package he got from a mirror is safe.


Costs: A little more traffic by serving hash files to everyone plus the
cost of the certificate from a CA. Is the income Arch receives from
ads and schwag enough for such a simple solution?



Dimitris

On 06/15/2010 04:57 PM, Dimitrios Apostolou wrote:

On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:

And keep in mind that package signing per se will not solve this kind
of problems. Repository database signing is more important for that
solution, but is a problem in the current workflow of Arch developers.


How exactly is core and extra database populated?


repo-add reponame.db.tar.gz packagefile.

on the server we have db-core/extra/testing, which checkouts the package
build from svn, compare the version and then copy into the directory and
running repo-add




Moreover, instead of building all packages in the private PCs of
developers, I think it is preferable to submit PKGBUILDs to build
servers (via web interface maybe) and let the servers do the build +
signing + repoupdate... That way if a developer's system gets
compromised his packages will stay clean. Of course that needs extra
work and equipment, but perhaps we can agree to it as a future target.



i found this annoying since, debugging is more harder, i have to
download the resulted package to test it, send it, wait for the pool to
come. is a mess


even if my system is compromised, we build our packages in clean chroots.


--
IonuÈ›

Tue Jun 15 16:30:01 2010
Return-path: <centos-bounces@centos.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 15 Jun 2010 16:20:48 +0300
Received: from mail.centos.org ([72.26.200.202]:35979)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <centos-bounces@centos.org>)
id 1OOW4O-0004xL-Br
for tom@linux-archive.org; Tue, 15 Jun 2010 16:20:48 +0300
Received: from mail.centos.org (voxeldev.centos.org [127.0.0.1])
by mail.centos.org (Postfix) with ESMTP id 283256F6B1;
Tue, 15 Jun 2010 09:59:36 -0400 (EDT)
X-Original-To: centos@centos.org
Delivered-To: centos@centos.org
Received: from mail.filmakademie.de (mail.filmakademie.de [193.196.129.3])
by mail.centos.org (Postfix) with ESMTP id 0A36767B45
for <centos@centos.org>; Tue, 15 Jun 2010 09:59:33 -0400 (EDT)
Received: from mac10337.local ([172.17.22.29]) (authenticated bits=0)
by mail.filmakademie.de (8.13.8/8.13.8) with ESMTP id o5FDxWcD018713
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO)
for <centos@centos.org>; Tue, 15 Jun 2010 15:59:32 +0200
Message-ID: <4C178744.7040307@filmakademie.de>
Date: Tue, 15 Jun 2010 15:59:32 +0200
From: =?ISO-8859-15?Q?G�Reinicke_-_IT-Koordinator? <goetz.reinicke@filmakademie.de>
Organization: Filmakademie =?ISO-8859-15?Q?Baden-W�berg_GmbH?User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de;
rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: CentOS mailing list <centos@centos.org>
X-Enigmail-Version: 1.0.1
X-Filmakademie-MailScanner-Information: Please contact the ISP for more
information
X-Filmakademie-MailScanner-ID: o5FDxWcD018713
X-Filmakademie-MailScanner: Found to be clean
X-Filmakademie-MailScanner-SpamCheck: not spam,
SpamAssassin (nicht zwischen gespeichert, Wertung=-16.8,
benoetigt 3.6, autolearn=disabled, ALL_TRUSTED -1.80,
BAYES_00 -15.00)
X-Filmakademie-MailScanner-From: goetz.reinicke@filmakademie.de
Subject: [CentOS] how to set up pam_oddjob_mkhomedir (samba and ldap)?
X-BeenThere: centos@centos.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: CentOS mailing list <centos@centos.org>
List-Id: CentOS mailing list <centos.centos.org>
List-Unsubscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=unsubscribe>
List-Archive: <http://lists.centos.org/pipermail/centos>
List-Post: <mailto:centos@centos.org>
List-Help: <mailto:centos-request@centos.org?subject=help>
List-Subscribe: <http://lists.centos.org/mailman/listinfo/centos>,
<mailto:centos-request@centos.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: centos-bounces@centos.org
Errors-To: centos-bounces@centos.org

Hi,

I do have a samba server up and running and users are authenticated by ldap.

Login to the samba server works as long as the user has a home directory.

Now if I create a new ldap entry for an user I'd like to use
pam_oddjob_mkhomedir to create a home directory if it dose not exist on
login.

But something fails on my system.

I followed the redhat faq http://kbase.redhat.com/faq/docs/DOC-3973
which may be wron according to that bugzilla entry.

https://bugzilla.redhat.com/show_bug.cgi?id=429524

So I added

session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022

to

/etc/pam.d/login

using all other default settings and configs using the rpms provided by
redhat EL 5.5 / Centos 5.5


rpm -qa|grep oddjob
oddjob-0.27-9.el5
oddjob-libs-0.27-9.el5

the services are restarted, there are no errors in the log except from
samba, that the login from the user fails because of the missing home
directory.

I'd appreciate any suggestion and best regards

G�
--
G�Reinicke
IT-Koordinator

Tel. +49 7141 969 420
Fax +49 7141 969 55 420
E-Mail goetz.reinicke@filmakademie.de

Filmakademie Baden-W�berg GmbH
Akademiehof 10
71638 Ludwigsburg
www.filmakademie.de

Eintragung Amtsgericht Stuttgart HRB 205016
Vorsitzende des Aufsichtsrats:
Prof. Dr. Claudia H�
Gesch�sf�
Prof. Thomas Schadt
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:

On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:

Moreover, instead of building all packages in the private PCs of developers,
I think it is preferable to submit PKGBUILDs to build servers (via web
interface maybe) and let the servers do the build + signing + repoupdate...
That way if a developer's system gets compromised his packages will stay
clean. Of course that needs extra work and equipment, but perhaps we can
agree to it as a future target.


Well, in fact, that is the very problem we have. The repository
database files are created remotely and I think that we should avoid
signing files remotely. In fact, a dev's machine is less visible than
the servers of Arch. And sse the response from Ionut too.


Let me just clarify here that by "build server" I mean a machine where
developers have *not* shell access (and in fact almost nobody has), and by
"package signing" I mean signing with a specific archlinux key which is
unknown (the private part) to most devs. Some distros follow that approach
to security.


What you are proposing is package signing by developer keys,
that's a different approach. I am just bringing up alternatives.



Dimitris


BTW I don't think that building inside a compromised system is in any way
secure, even if building inside a chroot.

On Tue, 15 Jun 2010 19:23:14 +0300, Aleksis Jauntēvs
<aleksis.jauntevs@gmail.com> wrote:
> I dont think that repo.db should be signed and it is enough to sign only
> the
> packages. As I understand so far the only reason to sign repo.db file is
> to
> prevent "replay" situations in repos.

It's the other way round: signing the DB is important while signing single
packages is not (but should still be done for some reasons).

If the DB is not signed I could simply add additional packages or replace
packages.

--
Pierre Schmitz, https://users.archlinux.de/~pierre

Just to clarify the build process that goes on here:

1) make a clean chroot (mkarchroot - only needs done once)
2) build package in chroot (makechrootpkg)
3) upload package to staging area and commit to svn (e.g. testingpkg)
4) release package on master server adding it to repo (e.g. db-testing)

Note, no remote build server....

The current code allows:
- Signing a package at the end of a build
- Adding the package signature to the repo-db
- pacman checking that signature

The question remains if/how to signing the repo db.

Options:
- do not sign the repo-db
- sign the repo-db with a key kept on the remote server
- transfer the repo-db locally and sign the reupload (alternatively,
sign a hash).


Why exactly is the repo-db needing signed? There is a risk that a
mirror could keep updating except for select packages that have
exploitable vulnerabilities in them. That would be prevented by repo
signing as the mirror would have to update all packages or none. The
argument that anybody could just add or replace packages is incorrect as
there either would not be a signed package added or it would be signed
with a non-trusted signature. I believe there is an option for pacman
to enforce package signing for a given repo so I do not see the risk there.


Signing directly on the remote server is also probably not the best
idea. We know our server has been attacked in the past, so leaving the
key to sign the repo database on there is stupid...


The repo db sizes are small so transfering them to be signed, and
transfering the signature back should be relatively quick. Even quicker
once we can convert them to .xz compression (patch already available the
release after next). I think that could be implemented by moving the
package release (step 4 above) to occur on the developers local machine
rather than on the remote server as that would require ssh access only
from the developers machine to the master server and not the other way
around. That seems more in the realm of devtools/dbscripts requiring
changes that makepkg/pacman.


Allan

On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:

The proposed model is based on the web of trust. We would trust on
some keys to sign other keys. The main keys would be kept by some high
trusty developers. They would sign the public keys of the other
developers (and their personal keys too) with the main ones. We,
mortal users, would trust the main keys to sign the others, and files
signed by the developers' keys would be considered valid, by
transitivity of the trust model.

So, if a developer's key is compromised, it would be enough to
generate another, submit to the key signers and resign the packages
affected. In the current workflow, the package building is made in
chroots, in the machine of each developer (sound reasons given by
Ionut, above). The package would be signed after him testing it. The
package would be upload to a staging area and the repo.db would be
created. At this point, the repo.db should be signed, but exactly how
is the real problem. I have some ideas, as explained in the wiki page,
but I don't have the time and my skills are not so wonderful. This is
done by Debian and Fedora, at least (those were what I've searched.
Others may do it the same way).


As far as I know, Fedora uses a different model: a build server and
release-wide keys. Search for "Fedora koji" and "Fedora keys" for more
info. However I don't know how do developers submit RPM spec files to the
build server, /maybe/ their own keys are used there.


About debian I don't have a clue.


Dimitris




And one more thing: the implementation is not the main concern. The
process is. That's why we muse discuss it thoroughly. A good plan will
lead to a good and secure implementation. We should not rush anything.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
-------------------------------------------