Privilidge Separation in sshd

This was accepted into openssh sometime in 2002.  It helps make openssh exploits more difficult in terms of gaining root.

Do a ps -ef on your system where an underprivilidged user is logged in via ssh.  eg

# ps -ef |grep sshd |grep myuser
root       28694  7865  0 Mar25 ?        00:00:00 sshd: myuser [priv]
myuser     28703 28694  0 Mar25 ?        00:00:00 sshd: myuser@pts/2

While that [priv] may seem disconcerting, it (by itself) shouldn’t be.  There is privilege seperation in sshd  so that if an exploit is found in the child does not result in a system compromise.

http://www.citi.umich.edu/u/provos/ssh/privsep.html

Small Steps

These are some small steps you can take to make it harder for an attacker to figure out what version of some things you have running. These are specific to ubuntu:

apache

Go into /etc/apache2/apache2.conf and change

ServerTokens Full

to

ServerTokens Prod

This will change your info for things like 404s, so instead of listing your exact os, version of apache, etc, it will only say something like ‘Apache Server at progeny.isu.edu Port 80′

postfix

change the smtpd_banner line to something like “smtpd_banner = $myhostname ESMTP $mail_name (Linux)” which will be much harder to figure out than all the crap this normally prints, which, once again, is the exact version of postfix you are running along with the os.

bind

By default, bind also lets people know all this info.  You can change this by changing the version = lines as follows

options {

version “back off, dirt bag!”;

}

Though many of these services can still be fingerprinted without too much effort, not reporting your version info for every service you run is probably a good idea.  So, for example, because of this, you may have a harder time figuring out that this server is running apache2.2 on ubuntu7.04 and postfix2.5… damn it.

getfacl, setfacl

From http://www.suse.de/~agruen/acl/linux-acls/online/

Traditionally, systems that support the POSIX (Portable Operating System Interface) family of standards [11,2] share a simple yet powerful file system permission model: Every file system object is associated with three sets of permissions that define access for the owner, the owning group, and for others. Each set may contain Read (r), Write (w), and Execute (x) permissions. This scheme is implemented using only nine bits for each object. In addition to these nine bits, the Set User Id, Set Group Id, and Sticky bits are used for a number of special cases. Many introductory and advanced texts on the UNIX operating system describe this model [19].

But there are obviously times this is insufficient.  Like, say Bob is working in a group with Alice, so he wants to share files with her, but they don’t want to share files with everybody else.  I guess root could go and create a group, add Bob and Alice to it, then they could set the file to the new group or whatever, but this becomes unmanagable with very large systems.

A short definition from the man page of what an ACL is

This manual page describes POSIX Access Control Lists, which are used to define more fine-grained discretionary access rights for files and directories.”

The following tags are defined

ACL_USER_OBJ The ACL_USER_OBJ entry denotes access rights for the file owner.
ACL_USER ACL_USER entries denote access rights for users identified by the entry’s qualifier.ACL_GROUP_OBJ The
ACL_GROUP_OBJ entry denotes access rights for the file group.
ACL_GROUP ACL_GROUP entries denote access rights for groups identified by the entry’s qualifier.
ACL_MASK The ACL_MASK entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.
ACL_OTHER The ACL_OTHER entry denotes access rights for processes that do not match any other entry in the ACL.

When an access check is performed, the ACL_USER_OBJ and ACL_USER entries are tested against the effective user ID. The effective group ID, as well as all supplementary group IDs are tested against the ACL_GROUP_OBJ and ACL_GROUP entries.

I won’t go into the not-really-that-gory details of how to implement it here, other than to say ACLs can be easily modified with the getfacl and setfacl commands.

So for example, if Alice wanted to give Bob read access to a file, she could type

$ setfacl -m u:Bob:r myfile

Follow

Get every new post delivered to your Inbox.