[crux-devel] meeting notes & next IRC Meeting
predatorfreak at dcaf-security.org
Wed May 31 20:28:50 UTC 2006
On Wed, 31 May 2006 20:52:50 +0200
Daniel Mueller wrote:
> I hope Anton and Brett will read this mail as well - I'll try to answer all
> open questions within this mail.
> On Wednesday 31 May 2006 08:07, Mark Rosenstand wrote:
> > Are you sayng that it's time to re-evaluate the priorities of the CRUX
> > project?
> > > Only to make that clear: PAM is the de facto standard (ALL major Linux
> > > distributions ship it).
> > And RPM is the standard package manager... ;)
> You are comparing apples and oranges. There are lots of alternatives for RPM
> (dpkg, pkgutils, ..). If you want your linux box joining a corporate network
> with centralized password management (ldap, samba/ad or kerberos) -> PAM is
> your (only) choice (AND YES: I know about "NIS" which works fully PAM-less
> and is insecure as hell AND I know various commercial products I don't want
> to talk about 'cause they just suck).
> > [..] svn.driver and making it the default, people could just edit the ports
> > and (non-conflicting) changes get automatically merged. This is what I
> > do, and it isn't that much slower than rsync.
> Hmm, I think you've missed my point here. I don't want a separated ports
> collection. We are not talking about one or two 'conflicting' ports. PAM
> is .. comprehensive (in words: all programs, libraries and tools dealing with
> passwords/authentication). However, in most cases it's just an additional
> configure switch and sometimes a (pre-configured!) service file placed
> in /etc/pam.d/. Joe User won't even notice that he's using PAM.
> > > Let me quote some words I found on CRUX's main page "[..] targeted at
> > > experienced Linux users", "The secondary focus is utilization of new
> > > Linux features and recent tools and libraries".
> > You accidently forgot this one: "The primary focus of this distribution
> > is keep it simple"
> I knowingly left it out. "KISS" Really, I start to hate these four letters.
> It's the ultimate power abbreviation to choke new ideas and concepts.
I don't try to choke new concepts at ALL, but CRUX IS a KISS distro and
we shouldn't start violating it's primary concepts
> On Wednesday 31 May 2006 01:20, Anton wrote:
> > > is the de facto standard (ALL major Linux distributions ship it).
> > Oh. You are very very wrong. Slackware do not use PAM by default, afaik.
> > It's on 11 place according to distrowatch.
> Ieeeeek! Shame on me! -> ALL - 1 major Linux distr....
> > Unfortunately it's not impressive, as I don't have retinal scaner, and
> > I don't want to play ``shoot 'em up'' game on login phase. ;-)
> > It's not clear to me why I'm, as crux user, have to use PAM. May be I
> > would love it if someone explain to me what it gives.
> Besides of the fact that you will get the possibility to join a corporate
> network with centralized password management, imagine the following scenario:
> You've got a brand-new laptop. Your new laptop has the disadvantage of being a
> popular object of desire for pilferers. The harddisk contains most likely
> private data (e.g. nude pics of your girlfriend). It's a good idea to encrypt
> those private files. I hear you saying "Bah, no problem, I don't need PAM for
> this". Okay; you would probably create some container files in your home
> directory and mount them if needed. Now let's imagine the thief is a smart
> one and he's looking for tracks in your home directory
> (.bash_history, .kde/*, .gnome/*, thumbails/* ..).
> With PAM (pam_mount) it's possible to mount encrypted filesystems during the
> logon session. That means you could encrypt your whole home directory and
> mount it automaticlly during login. After you've logged out, PAM will unmount
> it for you.
> Of course, you could do the same in some different ways (Many roads lead to
> Rome).. It was just an example of PAM's numerous capabilities. At the moment
> I'm enjoying little goodies like xauth forwarding when using su(1). (You may
> know this message: Xlib: connection to ":0.0" refused by server)
I have gnupg and that tends to be decent enough for 99% of my work, the
other things I clean manually every now and then. Plus, by the time a
hacker has gained access enough to remove my drive or read my data,
basically anything is screwed right then and there, I just use gpg on
stuff I prefer to keep private. Encryption does screw him over in the
terms that if he just removes my drive and mounts it, he'll get nothing
of worth, but seriously, he's more likely to get through my password
and upload the data somewhere.
This only becomes a serious problem when you start to talk about
laptops, but if you leave your laptop unattended, your asking for
whatever you get.
> On Wednesday 31 May 2006 05:38, Brett Goulder wrote:
> > It's a complex piece of code prone to problems and tends to introduce so
> > much excess that I do NOT use, I figure that most people who just need a
> > simple log in system as I do would also get annoyed.
> I really don't know how to answer this. Sounds like you just hate PAM and I'm
> sure I cannot convince you of the opposite. But that's okay.
> PAM could cause problems, yes. But I still hope we can solve as much as
> possible at the outset with a proper default configuration.
> > I'm a minimalist, I try to keep things as simple as possible, and I
> > wouldn't be able to deal with having excess such as PAM on my system, as it
> > contradicts my commitment to minimalist (one of the major reasons I choose
> > CRUX and stuck with it was that it was minimalist out of the box).
> Is CRUX a minimalist Linux distribution? I started with CRUX 0.7 or 0.8. At
> that time Per spoke of "lightweight", "i686-optimized" and "A distribution
> without useless or obsolete files" (so called junk files: README, INSTALL,
> bla). Did I misunderstand his primary goal from the beginning?
> > Complexity of implementation and design, PAM is both implementation complex
> > AND design complex, it rolls over the concept of KISS like a steamroller.
> It's not _that_ hard. The pam(8) manpage gives you a short overview with just
> 96 lines of text. It also says:
> "From the point of view of the system administrator, for whom this manual is
> provided, it is not of primary importance to understand the internal behavior
> of the Linux-PAM library."
> By the way, a lot of pam modules provide their own manpage (e.g. man 8
> Yesterday I summarized PAM enabled core ports in a tarball (cracklib,
> linux-pam, openssh, shadow).
>From my point of view, I must know what is going on behind-the-scenes,
I do not like things happening behind my back and PAM introduces a
whole lot of that. Complex systems like PAM introduce overhead in terms
of knowing your security system, you need to know every-single-part of
PAM too possibly know your own security system and that is just fscking
crazy, on top of that, I can cite at least one instance where PAM
caused an otherwise avoidable problem (it was a vulnerability in openssh).
> I'd like to thank you guys for your answers :-). They gave me an impression of
> what CRUX users think about my (revolutionary?) ideas and what I'll do in
> bye, danm
>  http://crux.danm.de/files/x86/pam/pam-ports.tar.gz
> Daniel Mueller
> Berlin, Germany OpenPGP: 1024D/E4F4383A
> crux-devel mailing list
> crux-devel at lists.crux.nu
GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the crux-devel