LINUX NEWS
Resources & Links From CramSession.com
Thursday, November 15, 2001TABLE OF CONTENTS
1) Sean’s Notes
2) Linux News
YOPY Uncovered
Sendmail Security Upgrade
XP Equals eXtra Proprietary
VA Spinoff Releases Product3) Linux Resources
Printing to PDF for Windows Users
Cisco VPN Client and Netfilter Conflict
Top 31 Things to Know for the RHCE
Need Some Help With Those Backups?
Using a SUN Blade?4) App o’ the week
~~~~~~~~~~~~~~~~~~~~~~ ADVERTISEMENT ~~~~~~~~~~~~~~~~~~~~~~~
Why pay a personal MS trainer $8,000 for 60 hours of their time, when you can have unlimited access to your own, for only $299?! CBTnuggets offers high quality training videos that walk you through your entire Windows 2000 training. You can view sample clips, read a product review if you are not yet convinced, or go ahead and buy them now.
http://ad.brainbuzz.com/?RC06&AI$59
For information on how to advertise in this newsletter
please contact mailto:adsales@CramSession.com or visit
http://cramsession.com/marketing/default.asp
-------------------------
1) Sean's Notes
-------------------------
One of the many complex parts of the operating system is the
way that it handles logins. Today, a Linux box can store
passwords and other authentication information pretty much
anywhere, from a local password file to an LDAP server
across the world. This flexibility is mostly due to the
system called PAM, or the Pluggable Authentication Modules.
In the early days of Linux, passwords were checked against
/etc/passwd. One of the fields in that file was an encrypted
hash of the user's password. The neat thing about hashes is
that they are one way, so "hello" may hash into "s3Dlam9U", but
given "s3Dlam9U" I can't get "hello". Of course, /etc/passwd
is world readable, so these hashes are freely available.
Someone with enough CPU could start hashing dictionary words
and check the result against the system's hash, and a match
would give them the password. Clearly, something needed to
be done. The answer was to separate the password hashes from
/etc/passwd and store them somewhere only a privileged user
could access. This is called shadowing, and is done on pretty
much every UNIX system out there now.
Most of the password checking functionality was built into
the applications themselves, meaning they had to be rebuilt
with the new features. Obviously, this doesn't scale well,
since adding more authentication methods means that more and
more programs will have to be continuously fixed up. SUN
came up with the idea of PAM, which further abstracts the
authentication functions by wrapping them in the PAM
libraries. Applications then talk to PAM and get back a
yes/no answer, rather than worrying about the specifics.
PAM works by providing four services:
auth - checks authentication tokens, such as passwords
account- verifies the user can log in, has an account, and is
not otherwise restricted
password - takes care of updating passwords
session - performs actions before and after the user logs in,
such as setting permissions on devices, mounting
directories, etc.
A shared library is used to implement one or more of the above,
and they live in /lib/security. For example, pam_unix.so is
responsible for providing traditional unix features like
/etc/password and NIS. If I wanted to verify a password
against the shadowed password file, I'd use pam_unix.
PAM requires that services define themselves, and the services
that they require. Each service has a file in /etc/pam.d,
listing the services they need. The login service, which
handles your telnet and console logins, looks as follows.
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
session optional /lib/security/pam_console.so
Each service is on the left, followed by either required,
requisite, sufficient, or optional, and then the path to
the shared library that will answer. Options can be passed
(as in service=system-auth) to add flexibility.
Subtle differences aside, required and requisite are the same.
If any line fails, the whole service fails. In the above
example, auth will fail if any of securetty, stack, or nologin
fail. The items are processed in order, so in order to
succeed at the auth service, securetty has to return OK
(prevents users from logging in as root remotely), stack has
to return OK (more later), and nologin too (can be used to
disable logins on a global basis).
An optional flag doesn't really matter, unless it is the only
one. Above, session lists console as an optional method.
Since pam_console.so's job is to set device permissions if
the user is logged into the console, it doesn't have any
bearing on security if it returns successful or not.
Something that is sufficient can be used to stop checking
the stack, such as when you want to authenticate against
several sources, but only use the first one that works.
pam_stack is a helpful module, as its job is to consolidate
other PAM files. "service=system-auth" tells PAM that it is
to jump to the system-auth file and process it, and return
the result. Thus, you can make some options take effect on
a more global level.
If you take a look at the files in /etc/pam.d, most of them
stack the system-auth file within them. One of the things
that it does in the password service is try to crack the
password before letting you change it. Thus, no matter
what authentication scheme you use, you can enforce a
secure password policy.
There are a lot of modules (over 30 on my Red Hat 7.1 system),
meaning that the ability exists to enforce millions of policy
combinations in a method transparent to the user.
Don't only think of PAM as the system that lets you
authenticate against different services, but as a system that
can enhance the user interface by hiding the root user.
Much of the configuration software uses PAM to pop up a root
password dialogue rather than failing outright.
One example is shutting down the system. Traditionally, you
have to su to root (surprise, surprise, another app that uses
PAM, see /etc/pam.d/su), and then execute "halt". By making
/usr/bin/halt PAM aware, the rights to halt a system can be
specified in a file (/etc/pam.d/halt):
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_console.so
account required /lib/security/pam_permit.so
In this case, the user either has to be root (rootok's job),
or be logged into the console. Much cleaner!
So, not only does PAM let you transparently work with
authentication schemes, it can hide some of the root jobs
from the user.
Red Hat's chapter on PAM:
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/c
h-pam.html
Good man pages:
consolehelper
userhelper
pam
Documentation on most of the PAM modules:
/usr/share/doc/pam\*
PAM libraries:
/lib/security/\*.so
PAM configs:
/etc/pam.d
Other PAM modules can be found on freshmeat.net, including
pam_smb, which authenticates against an NT SAM.
Long live the Penguin,
Sean
mailto:swalberg@cramsession.com
Visit the Linux News Board at
http://boards.brainbuzz.com/boards/vbt.asp?b2
-------------------------
2) Linux News
-------------------------
---------------
YOPY Uncovered
---------------
Linux powered PDAs have been relatively quiet lately, which
is why this link stuck out. This article has some good
pictures of this little device, showing off its most
unusual design.
http://www.infosync.no/show.php?id06&page=1
--------------------------
Sendmail Security Upgrade
--------------------------
It has been a little while since we've seen serious security
bugs in sendmail, a popular message transfer agent (MTA). It
would appear that this one has to do with command line
processing, so it's a local exploit only. 8.11.6 fixes all
that, and also brings the company to the point where they're
almost ready with 8.12.0.
http://www.sendmail.org/8.11.html
----------------------------
XP Equals eXtra Proprietary
----------------------------
The CTO of Red Hat lets it fly at Microsoft regarding how
XP further enhances Microsoft's monopoly. While the advice
at the end of the article is no surprise (ditch Windows,
use Linux), the arguments are excellent, and well worth
the read.
http://www.redhat.com/about/opinions/xp.html
----------------------------
VA Spinoff Releases Product
----------------------------
"A Web services company that was bought by VA Linux last
fall, then sold back to one of its founders this summer,
released its first product last week and is projecting
profitability any day now."
http://www.newsforge.com/article.pl?sid/11/12/2320209
-------------------------
3) Linux Resources
-------------------------
----------------------------------
Printing to PDF for Windows Users
----------------------------------
Generating a PDF is a pretty easy task under Unix--the
ghostscript package makes this simple. Under Windows,
though, you're expected to fork out a few hundred dollars
for the same privilege. Samba will allow you to hook a
Windows client into the deal, and save a bundle of cash in
the process.
http://www.linuxgazette.com/issue72/bright.html
----------------------------------------
Cisco VPN Client and Netfilter Conflict
----------------------------------------
For those of you using the Cisco VPN client for Linux, you
may have noticed that it has a habit of hanging your system.
Turns out it's a known bug: the kernel module used for the
client and netfilter conflict. Until Cisco gets this one
fixed, you'll need to compile out netfilter. CCO access is
required to view this, sorry.
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdv2
2799
-----------------------------------
Top 31 Things to Know for the RHCE
-----------------------------------
Red Hat publishes a list of 31 items one has to know to pass
the Red Hat Certified Engineer exams. This article has that
list, along with some good links for each item to help you
learn the topic.
http://www.unixreview.com/documents/s56/urm0109a/
-----------------------------------
Need Some Help With Those Backups?
-----------------------------------
I'm a believer in the "He who laughs last probably made a
backup" approach to system administration. What I'm not
FTP'ing off site, I'm dumping to tape. This page has some
great help for those looking for ways to back up their
information.
http://www.linux-backup.net/app.gwif.html
-------------------
Using a SUN Blade?
-------------------
SUN has a fairly inexpensive, high quality machine out there.
At the latest meeting of the Linux User's Group I attend,
there was some discussion about this device, called the Sun
Blade. The unofficial FAQ is very good, though at the time
of writing it is unavailable. Google's Cache has a good copy
of this document, which includes information on how to upgrade
it with off-the-shelf hardware.
http://www.google.com/search?hl=en&client=googlet&q=sun+blade+faq
-------------------------
4) App o' the week
-------------------------
I picked up a book the other day on a product called Zope,
which is an Open Sourced web application server based around
Python. The range of things it can do is simply amazing, and
since it uses the Python language, is fairly easy to start
learning. This is definitely a step up from PHP (still an
excellent product) in terms of rapid development and
availability of components.
http://www.zope.org
-------------------------
(C) 2001 BrainBuzz.com, Inc. All Rights Reserved.
-------------------------
-------------------------
This message is from CramSession.com.
You are currently subscribed to the
Hottest Linux News and Resources
as: sean@ertw.com
To un-subscribe from this newsletter by e-mail:
send a blank email message to:
mailto:leave-linuxnews-3825955Y@list.cramsession.com
-------------------------------------------------------
To Subscribe to this newsletter by e-mail:
send a blank email message to:
mailto:join-linuxnews@list.cramsession.com
-------------------------