- What are the various authentication
methods?
There are two main authentication methods:
a) local passwords - Do not use "AFS" passwords.
b) AFS (kerberos) passwords
Both are controlled via pam. When installing SULinux, you'll be asked
if you want to use AFS passwords. This means that in
/etc/pam.d/system-auth a line will be inserted that gives the
following logic for login:
- Does the account name exist? If no, you will not be able to log in
- Is the login name "root"? If so, prompt only for local password
- Prompt for "AFS Password", which is the kerberos password for the
given ID. Note that if you duplicate a SUNeT ID on your machine,
that SUNeT ID will be able to log into your system. AFS passwords
are "sufficient" in the PAM sense, so if this password is correct,
the person can log in
- If the AFS password is wrong, prompt for local password.
This may not be what you want. If you only want to use local
passwords, do not use the AFS auth mechanism. Suppose you want to
allow all SUNeT ID's to log in. You again use the PAM module, buth
also run "authconfig" and configure hesiod support (just check it, the
values should be filled in automatically). Hesiod will act as an
addition to your /etc/passwd, mapping user names to home directories
(AFS directories, mind you). Please see the hesiod documentation in
redhat for more information on how hesiod works.
Another possibility is you want the local users to auth using *both*
their local ID and their SUNeT ID. To do this, you must edit the PAM
configuration. I personally have not done this, but I believe all you
should have to do is change the word "sufficient" for the PAM AFS
module to "necessary". If you can confirm this, please email
sulinux-help and let me know.
The last possibility is you want leland system cluster solaris style
auth, i.e. AFS passwords but reading .klogin to map user names to
SUNeT IDs. Notice the subtle difference. In the default scheme, the
username in /etc/passwd maps directly and automatically to a SUNeT ID
for normal users. In this scheme, the username in /etc/passwd doesn't
correspond to a SUNeT ID, but any principle (SUNeT ID) listed in the
home directories .klogin file can log in. To enable this, replace
/bin/login with /etc/leland/login.krb. NOTE: login.krb doesn't
work with MD5 shadow files, so please make sure you use the old style
"crypt()" passwords. Please make sure you know what you are doing, as
you can mess up your system so you can only log in in single user
mode until you fix it.
- Why is NFS disabled?
NFS and other RPC based programs are a big security risk for several
reasons. First, they have a less than admirable record. Most Linux
compromises on campus come from users who have enabled NFS and other
RPC services and forgot to patch them. Second, NFS and other RPC
services have horrendous logging, which makes it difficult to track
what is going on. Third, NFS has traditionally been hard to set up
properly, though Linux is making strong in-roads in this department.
Last, NFS just plain isn't needed by most people. You need not run
the service if you only want to mount other hosts filesystems.
You only need to run NFS if you absolutely must export one of your
filesystems.
- Why is autofs disabled?
See the NFS answer above and substitute the
word NFS for AutoFS.
- 2. How do I re-enable NFS?
The most important step to re-enable NFS is to apply all
updates to NFS packages. Updates are available from the SULinux
server in the appropriate updates directory.
After installing the updates, run as root:
# /sbin/chkconfig portmap on
# /sbin/chkconfig nfs on
# /etc/rc.d/init.d/portmap start
# /etc/rc.d/init.d/nfs start
- How do I re-enable AutoFS?
Again, the most important step to re-enable AutoFS is to apply all
updates to NFS packages. Updates are available from the SULinux
server in the appropriate updates directory.
After installing the updates, run as root:
# /sbin/chkconfig portmap on
# /sbin/chkconfig autofs on
# /etc/rc.d/init.d/portmap start
# /etc/rc.d/init.d/autofs start
- What is AFS?
AFS is a distributed filesystem that enables co-operating hosts
(clients and servers) to efficiently share filesystem resources
across both
local and wide area networks. AFS is provided and supported by
Transarc Corporation.
At Stanford, Leland Systems uses AFS to provide and maintain a
campus-wide distributed filesystem -- the ir.stanford.edu AFS
cell. This cell currently consists of twenty AFS servers,
geographically distributed across campus, and one Terabyte of
available
diskspace, which is backed up nightly.
Leland Systems uses this AFS cell to provide home directories for
all Leland Accounts, many Stanford classes, and many Stanford
University departments and campus organizations. Our AFS cell is
also the home for our /usr/pubsw campus software service, which
allows AFS client machines (for a variety of supported
architectures) to access and use software compiled and maintained
by Leland
Systems personnel.
Over a thousand machines on the Stanford campus run AFS client
software, giving their users local access to their Leland Account
home
directory, all the software available in /usr/pubsw, and hundreds
of other AFS cells worldwide.
- How do I enable AFS?
First, verify that afs is installed. If the file /etc/rc.d/init.d/afs
exists, it is installed on your system. If not, install it from
the download page.
To enable AFS, run as root:
# /sbin/chkconfig afs on
# /etc/rc.d/init.d/afs start
- How do I disable AFS?
Disabling AFS is tricky, as once started it becomes part of the
kernel. Therefore, you must:
- touch /etc/noafs
- reboot
- run
/sbin/chkconfig afs off
- What is Kerberos?
Kerberos is the basis of Stanford's Campus Security Infrastructure. It
provides encrypted communications channels and user and machine
authentication services. The Kerberos authentication servers managed
by Leland Systems keep track of all campus SunetID passwords.
- What is SSH?
SSH (Secure Shell) is a secure telnet-like protocol. It encrypts your
password so that eavesdroppers cannot steal it. More information
on SSH is available at http://www.openssh.org
- Who do I email for support?
If you have questions regarding the installation or use of RedHat
linux, please consult the RedHat website at http://www.redhat.com
If you have questions about the Kerberos, AFS, Security, or
LibSafe package or other SULinux-specific question, email sulinux-help@stanford.edu
- Is there a sulinux-help list
archive?
There sure is! It is available in our mail archive section.
- Why does libsafe make program (insert name
here) coredump?
Libsafe protects against buffer overflow attacks. A buffer
overflow is an exploit that executes code on the stack to give an
intruder full access to your machine (usually).
If a program isn't coded correctly, it may resemble an exploit.
This is similar to a "segmentation violation" in C. Libsafe will
force such a program to exit. Examples are old versions of
netscape and adobe acrobat reader. Quite likely if you simply
upgrade the package that is core dumping the problem will go away.
- What is libsafe?
Libsafe protects against buffer overflow attacks by preloading certain
dangerous C functions such as strcpy and sprintf. Libsafe will
make programs exit instead of allowing them to be exploited.
More information is available at http://www.avayalabs.com/project/libsafe/index.html
- How can I retrieve my mail from
the leland servers?
First, realize that only mail that is kept on one of the mail
servers can be retrieved. Mail that you previous downloaded
by running programs such as Eudora and pine will not be
available.
To get your mail, run:
$ /usr/bin/fetchmail -u (your sunet id) --ssl .pobox.stanford.edu
The first command gives you the mail server to type in for the
second command.
SULinux Help!