How to Limit Display of Other User's Processes

Friday Sep 24, 2004

This entry is a continuation of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS. In this update, I will be talking about how to restrict the output of the ps(1) command such that users can only see processes that they own. This is a very useful capability especially for ISPs and other organizations that do not want to allow users to see what other users are doing.

This new feature would not have been possible without the introduction of process privileges into the Solaris 10 OS. For a great overview of process privileges, see Casper Dik's blog entry on this topic. Be sure to read his article to get a more in depth understanding of process privileges.

So, before we begin, let's see what the output of ps -aef might look like for an average user (in this case, gmb):

$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    root     0     0   0   Sep 23 ?           0:07 sched
    root     1     0   0   Sep 23 ?           0:01 /sbin/init
    root     2     0   0   Sep 23 ?           0:00 pageout
    root     3     0   0   Sep 23 ?           2:31 fsflush
    root   393     1   0   Sep 23 ?           0:00 /usr/sbin/auditd
    root     7     1   0   Sep 23 ?           0:11 /lib/svc/bin/svc.startd
    root     9     1   0   Sep 23 ?           0:19 svc.configd
    root   176     1   0   Sep 23 ?           0:00 /usr/sbin/syslogd
    root    64     1   0   Sep 23 ?           0:00 /usr/sbin/nscd
  daemon    91     1   0   Sep 23 ?           0:02 kcfd
    root   170     1   0   Sep 23 ?           0:01 /usr/lib/utmpd
     gmb  1795  1792   0 22:17:26 pts/1       0:00 -sh
    root  1527     7   0 00:53:24 console     0:00 /usr/bin/login
    root    82     1   0   Sep 23 ?           0:00 /usr/lib/sysevent/syseventd
   smmsp   334     1   0   Sep 23 ?           0:00 /usr/lib/sendmail -Ac -q15m
  daemon   137     1   0   Sep 23 ?           0:06 /usr/sbin/rpcbind
    root    84     1   0   Sep 23 ?           0:00 /usr/lib/picl/picld
    root  1601  1527   0 07:36:19 console     0:00 -sh
    root   181     1   0   Sep 23 ?           0:04 /usr/lib/inet/inetd start
    root   281     1   0   Sep 23 ?           0:00 /usr/lib/nfs/mountd
    root   187     1   0   Sep 23 ?           0:00 /usr/sbin/cron
    root  1402     1   0 00:26:14 ?           0:00 /usr/lib/ssh/sshd
  daemon   289     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsd
  daemon   264     1   0   Sep 23 ?           0:00 /usr/lib/nfs/statd
    root   303     1   0   Sep 23 ?           0:00 /usr/lib/fm/fmd/fmd
  daemon   268     1   0   Sep 23 ?           0:00 /usr/lib/nfs/lockd
    root   291     1   0   Sep 23 ?           0:00 /usr/lib/autofs/automountd
     gmb  1799  1795   0 22:17:28 pts/1       0:00 ps -aef
    root  1789   181   1 22:17:19 ?           0:00 /usr/sbin/in.telnetd
    root  1792  1789   1 22:17:19 pts/1       0:00 login -p -h 10.1.1.100 -d /dev/pts/1
    root   335     1   0   Sep 23 ?           0:06 /usr/lib/sendmail -bd -q15m
  daemon   296     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsmapid

As you can see, the gmb user can see not only his processes but also those of the root, daemon, and smmsp accounts. We can change this behavior either globally or on a per-user basis. Just as we discussed in the Solaris 10 Account Lockout entry, we can use user-specific changes to force a subset of users to comply with some policy or use the user-specific changes to make exceptions for those users. The flexibility of this format allows it to be adapted quite easily to the needs of many organizations.

For our first example, we will illustrate how the global change can be made. So do this, we must edit the /etc/security/policy.conf file, uncomment the PRIV_DEFAULT entry and set its value as follows:

PRIV_DEFAULT=basic,!proc_info

For those not familiar with the proc_info privilege, you can find more information about it using the ppriv(1) command:

# ppriv -l -v proc_info
proc_info
        Allows a process to examine the status of processes other
        than those it can send signals to.  Processes which cannot
        be examined cannot be seen in /proc and appear not to exist.

This is all that you need to do to globally configure your Solaris 10 system so that users will only be able to see processes that they own. Note that this will obviously not apply to root who by default has all privileges or to other users or processes that have been explicitly given the proc_info privilege. Regardless, it is still a very quick and effective way to limit what processes users may see.

Returning to the gmb account example, I re-login to the system and again run the ps -aef command, but this time I receive different results:

$  ssh -l gmb sampleHost
gmb@sampleHost's password:
Last login: Fri Sep 24 22:25:18 2004 from 10.1.1.100
Sun Microsystems Inc.   SunOS 5.10      s10_67  May 2004
$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
     gmb  1823  1819   0 22:30:17 pts/1       0:00 ps -aef
     gmb  1819  1815   0 22:30:14 pts/1       0:00 -sh
$

As you can see, the gmb user may now only see his own processes. Way cool. Next, to illustrate the per-user configuration ability, I will leave this global configuration in place and use the per-user configuration ability to allow the gmb user to view processes owned by other users. This is just an example of how exceptions can be implemented. The same process could be used to enable this feature for just a user or subset of users on the system.

To accomplish this task, we go back to the user_attr(4) file. In this file, we will modify the existing entry for the gmb user (or create one if one had not already been there). The following example illustrates the change that needs to be made. Specifically you need to add the defaultpriv entry to specify the default list of privileges that will be available to this user. By modifying this parameter, you will change the default set of privileges available to a user (by either adding or removing privileges as needed.) In this case, we are returning the user's default set of privileges to basic from basic,!proc_info.

gmb::::lock_after_retries=no;defaultpriv=basic

So, let's see if this really works. In the following example, we will confirm the configuration of the system, login to the system as the gmb user, and run the ps -aef command to verify that the gmb user can see processes owned by other users.

# grep "^PRIV_DEFAULT=" /etc/security/policy.conf
PRIV_DEFAULT=basic,!proc_info
# grep "^gmb:" /etc/user_attr
gmb::::lock_after_retries=no;defaultpriv=basic
# ssh -l gmb localhost
Password:
Last login: Fri Sep 24 22:37:55 2004 from 10.1.1.100
Sun Microsystems Inc.   SunOS 5.10      s10_67  May 2004
$ id -a
uid=100(gmb) gid=1(other) groups=1(other)
$ ps -aef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    root     0     0   0   Sep 23 ?           0:07 sched
    root     1     0   0   Sep 23 ?           0:01 /sbin/init
    root     2     0   0   Sep 23 ?           0:00 pageout
    root     3     0   0   Sep 23 ?           2:33 fsflush
    root   393     1   0   Sep 23 ?           0:00 /usr/sbin/auditd
    root     7     1   0   Sep 23 ?           0:11 /lib/svc/bin/svc.startd
    root     9     1   0   Sep 23 ?           0:19 svc.configd
    root   176     1   0   Sep 23 ?           0:00 /usr/sbin/syslogd
    root    64     1   0   Sep 23 ?           0:00 /usr/sbin/nscd
  daemon    91     1   0   Sep 23 ?           0:02 kcfd
    root   170     1   0   Sep 23 ?           0:01 /usr/lib/utmpd
    root  1900  1402   7 22:42:05 ?           0:02 /usr/lib/ssh/sshd
    root  1527     7   0 00:53:24 console     0:00 /usr/bin/login
    root    82     1   0   Sep 23 ?           0:00 /usr/lib/sysevent/syseventd
   smmsp   334     1   0   Sep 23 ?           0:00 /usr/lib/sendmail -Ac -q15m
  daemon   137     1   0   Sep 23 ?           0:06 /usr/sbin/rpcbind
    root    84     1   0   Sep 23 ?           0:00 /usr/lib/picl/picld
    root  1601  1527   0 07:36:19 console     0:00 -sh
    root   181     1   0   Sep 23 ?           0:04 /usr/lib/inet/inetd start
    root   281     1   0   Sep 23 ?           0:00 /usr/lib/nfs/mountd
    root   187     1   0   Sep 23 ?           0:00 /usr/sbin/cron
    root  1402     1   0 00:26:14 ?           0:00 /usr/lib/ssh/sshd
  daemon   289     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsd
  daemon   264     1   0   Sep 23 ?           0:00 /usr/lib/nfs/statd
    root   303     1   0   Sep 23 ?           0:00 /usr/lib/fm/fmd/fmd
  daemon   268     1   0   Sep 23 ?           0:00 /usr/lib/nfs/lockd
    root   291     1   0   Sep 23 ?           0:00 /usr/lib/autofs/automountd
     gmb  1912  1908   0 22:42:12 pts/1       0:00 ps -aef
    root   335     1   0   Sep 23 ?           0:06 /usr/lib/sendmail -bd -q15m
  daemon   296     1   0   Sep 23 ?           0:00 /usr/lib/nfs/nfsmapid
     gmb  1908  1900   0 22:42:10 pts/1       0:00 -sh
    root  1899  1601   6 22:42:05 console     0:02 ssh -l gmb localhost

It worked! That was pretty easy, right? This is just one very small example of how you can use process privileges in your daily lives. I will try to add more interesting examples of practical uses for process privileges in the future.

Before ending, I do want to highlight that while these examples focused on the ps(1) command - other process related commands will also be impacted such as ptree(1), pcred(1), pmap(1), psig(1), etc. Further, as a user running without the proc_info privilege, you will not even be able to see other processes in the /proc directory:

$ id -a
uid=101(foo) gid=1(other) groups=1(other)
$ ppriv $$
1915:   -sh
flags = 
        E: basic,!proc_info
        I: basic,!proc_info
        P: basic,!proc_info
        L: all
$ ls -l /proc
total 4
dr-x--x--x   5 foo      other        832 Sep 24 22:52 1915
dr-x--x--x   5 foo      other        832 Sep 24 22:56 1932

I hope you enjoyed this article and please watch this space for new discussion of Solaris 10 security features. Take care and have a great weekend.

Technorati Tag: OpenSolaris Solaris security

Share and Enjoy!
Posted at 10:23PM Sep 24, 2004 by gbrunett in Solaris 10 Security Tags: nevada opensolaris privileges security solaris

Solaris 10 Account Lockout ("Three Strikes!")

Thursday Sep 23, 2004

The next item of my list of lesser known and/or publicized security enhancements to the Solaris 10 OS is account lockout. Account lockout is the ability of a system or service to administratively lock an account after that account has suffered "n" consecutive failed authentication attempts. Very often "n" is three hence the "three strikes" reference.

Recall from yesterday's entry on non-login and locked accounts that there is in fact a difference. Locked accounts are not able to access any system services whether interactively or through the use of delayed execution mechanisms such as cron(1M). So, when an account is locked out using this capability, only a system administrator is able to re-enable the account, using the passwd(1) command with the "-u" option.

Account lockout can be enabled in one of two ways. The first way will enable account lockout globally for all users. The second method will all more granular control of which users will or will not be subject to account lockout policy. Note that the account lockout capability will only apply to accounts local to the system. We will look at both in a little more detail below.

Before we look at how to enable or disable the account lockout policy, let's first take a look at how you configure the number of consecutive, failed authentication attempts that will serve as your line in the sand. Any number of consecutive, failed attempts beyond the number selected will result in the account being locked. This number is based on the RETRIES parameter in the /etc/default/login file. By default, this parameter is set to 5. You can certainly customize this parameter based on your local needs and policy. By default, the Solaris Security Toolkit will set the RETRIES parameter to 3.

Now that we know how to define how many consecutive, unsuccessful authentication attempts we will allow, let's take a look at how you can enable the account lockout policy globally. This policy can be altered using the LOCK_AFTER_RETRIES variable in the /etc/security/policy.conf file. Just as it sounds, if you set this parameter to YES, then the account lockout policy is enabled for all users on the system (unless there is a user override which we will talk about in a minute). By default, this parameter is set to NO which means that account lockout is not enabled.

So, let's try a simple example. First, I created a test account called gmb. Next, I set the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf to YES. To see, how this feature works, I attempted to authenticate to a system (and failed) using three different services:(1) TELNET, (2) FTP and (3) RLOGIN. I failed the login attempt for each of these services (in turn) twice with the exception of RLOGIN since after the fifth failed attempt the account was locked. I ran this test from the system's console so that the log messages could be injected into the output stream to give you a better idea of what was happening. Here is the actual log of the test that was run:

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: 
Connection to localhost closed by foreign host.
# ftp localhost
Connected to localhost.
220 sampleHost FTP server ready.
Name (localhost:root): gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> user gmb
331 Password required for gmb.
Password:
530 Login incorrect.
Login failed.
ftp> quit 221 Goodbye.
# rlogin -l gmb localhost Password:
Sep 23 23:23:47 sampleHost login: Excessive (5) login failures for gmb: locking account. Login incorrect
login: 

As you can see, after the fifth attempt, the gmb account was locked. This can also be verified by looking at the shadow(4) file entry for that account:

# grep "^gmb:" /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5 

You can see that the account has been locked and that a record of the number of failures is available in the last column. From the shadow(4) manual page, the last field (called "flag") stores the failed login count in the low order four bits while reserving the remainder for future use. This means that you can also look at individual shadow(4) entries and see how many consecutive failed authentication attempts have been made per user. For example, you could do the following to see how many users have had failed authentication attempts since their last successful login:

# awk -F: '$NF >= 1 { print; }' /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::5
foo:02YZb5ZaMrcrk:12685::::::2
bar:XF0Ggjq1c6tYQ:12685::::::1
baz:.VxOG4ytNE8es:12685::::::3

If a user who has had failed authentication attempts is finally able to successfully login to the system, that user will be presented with a message like:

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: baz
Password:
Warning: 3 failed login attempts since last successful login.
Last login: Thu Sep 23 23:36:44 from localhost

This warning message is available for interactive login services (not FTP) and is very helpful in providing warning to users who may not have been responsible for the failed authentication attempts. It is important that you educate your users to not simply ignore these messages as they could be a symptom of an ongoing attack on their account.

Also, note that once a user has successfully authenticated to a system, the failed login count is reset:

# grep "^baz" /etc/shadow
baz:.VxOG4ytNE8es:12685::::::

Note that the use of alternate authentication mechanisms such as rhosts or Secure Shell public key authentication will not reset the failed login count even on successful login. Should an account be locked however (either administratively or through the account lockout facility), the account would no longer be accessible even when using these alternate authentication methods. For example:

# grep gmb /etc/shadow
gmb:*LK*R12OfCMPngtJQ:12685::::::
# rsh -l gmb localhost /bin/finger
account expired

or for Secure Shell...

# ssh -l gmb -i /export/home/gmb/.ssh/id_dsa localhost
Enter passphrase for key '/export/home/gmb/.ssh/id_dsa':
Sep 24 00:34:59 sampleHost sshd[1504]: Failed publickey for gmb from 127.0.0.1 port 32801 ssh2
Password:

The second way in which account lockout can be configured is per-user in the /etc/user_attr file. Each user listed in the /etc/user_attr file can have an attribute defined called lock_after_retries. For a description of the format of this file, see the user_attr(4) manual page. By default, this value is set to no.

To configure account lockout for a specific user, simply add the lock_after_retries attribute with a value of yes. For example, let's assume you have an entry for user gmb:

gmb::::type=normal;profiles=FOO Security Management;roles=secadm

To enable account lockout, you simple change the above line to:

gmb::::type=normal;profiles=FOO Security Management;roles=secadm;lock_after_retries=yes

Let's take another view on this. Let's assume that the account lockout policy has been enabled globally using the method described above. You can then configure some users to be immune to this policy using this user-specific override. For example, if the LOCK_AFTER_RETRIES parameter was set to YES in /etc/security/policy.conf, but you did not want the policy to apply to the gmb account, then you only need to make sure that the /etc/user_attr file contains an entry for the gmb account that sets the lock_after_retries attribute to no as in:

gmb::::lock_after_retries=no

Here is an example of how this works. I will attempt to access the gmb account with an invalid password five times using TELNET. In contrast to the above example, the account should not be locked and no account locked message should be generated. First, let's confirm we have our system configured correctly for this test:

# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::::::
# grep "^gmb:" /etc/user_attr
gmb::::lock_after_retries=no
# grep "^LOCK_AFTER_RETRIES=" /etc/security/policy.conf
LOCK_AFTER_RETRIES=YES

Now, let's see if the account actually gets locked after 5 failed authentication attempts.

# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
login: gmb
Password:
Login incorrect
Sep 23 23:51:46 sampleHost login: REPEATED LOGIN FAILURES ON /dev/pts/1 FROM localhost, gmb
Connection to localhost closed by foreign host.
# grep "^gmb:" /etc/shadow
gmb:h8HsRoqrne1oQ:12685::::::

Just as expected, the gmb account is immune from the account lockout policy that applies to other users on the system. This is in fact what is implemented by default for the root account. That is, even if account lockout is enabled globally (which is not the default), the root account is still immune from being locked out. This is done to prevent a malicious user from locking the root account out of the system. If you would like this policy to apply to the root account, then simply change the value of the lock_after_retries parameter to yes in the /etc/user_attr file.

This concludes another installment. As always, I hope you find this information useful in understanding how some of the new Solaris 10 security enhancements work and how they can be applied to solve real-world problems in your environment.

Technorati Tag: OpenSolaris Solaris security

Share and Enjoy!
Posted at 03:37PM Sep 23, 2004 by gbrunett in Solaris 10 Security Tags: nevada opensolaris security solaris

Managing Non-Login and Locked Solaris Accounts

Tuesday Sep 21, 2004

Today's entry will focus on enhancements to the passwd(1) command to better support the distinction between locked and non-login accounts. Specifically, we will be looking at the new -u and -N options to the passwd(1) command as well as how they relate to the much older -l option. These new capabilities will help administrators obtain better control over how their accounts are accessed and how they can in fact manage those accounts. In the past, some of the interfaces discussed below could only be achieved through manual editing of password files. The addition of these new command line options provides a much safer option for administrators to use.

While the distinction between non-login and locked accounts has existed in Solaris for many years, it became more pronounced in Solaris 9 where the semantics of locked accounts were more rigidly enforced.

Many customers noticed, for example, that locked accounts could no longer execute jobs using cron(1M). This problem was exacerbated by the fact that many commonly referenced security recommendation guides tell users to lock all of the accounts to which interactive access was not needed (which is most of the default accounts). When this was done, cron jobs for accounts such as "sys" (used for collecting system activity records) stopped working. This problem highlighted the intended difference between non-login and locked accounts and the need for additional interfaces to control them.

For those not already aware, a non-login account is one that must exist on the system (to provide a UID for example) but should not be allowed to login to a system interactively. That is, while a non-login account may be able to leverage delayed execution mechanism such as cron(1M), they cannot access the system using login(1), telnet(1) ftp(1), ssh(1), etc. Accounts that are non-login will have the token NP as their password. You can also identify non-login accounts using the passwd(1) command:

# passwd -s daemon
daemon    NL
# grep "^daemon:" /etc/shadow
daemon:NP:6445::::::

In this case, the daemon account has been configured as a non-login account.

A locked account on the other hand is one that is not permitted to access the system in any way - it is locked. A locked account differs from one marked as non-login in that locked accounts are not permitted to use delayed execution methods like cron(1M). Locked accounts are those whose password string has the prefix *LK*. Further, you can identify locked accounts using the passwd(1) command:

# passwd -s listen
listen    LK
# grep "^listen:" /etc/shadow
listen:*LK*:::::::

In this case, the listen account has been locked.

Here is a practical example. In this case, I will add a new account gmb to the system. By default, new accounts created using useradd(1M) are locked. After assigning a new password, I will demonstrate the use and result of the new -N and -u options to the passwd(1) command in addition to the -l option which has been around for ever.

First, let's create a test account called gmb. You will notice that by default the account will be locked.

# useradd -d /export/home/gmb gmb
# passwd -s gmb
gmb       LK

Next, a password will be assigned to the gmb account in the usual way using the passwd(1) command...

# passwd gmb
New Password:
Re-enter new Password:
passwd: password successfully changed for gmb
# passwd -s gmb
gmb       PS
# grep "^gmb:" /etc/shadow
gmb:Onk28eSYhYJ8s:12683::::::

You will notice that the "passwd -s" command now returns the keyword PS for "password set". If the account did not have a password defined, the keyword NP (for "no password") would have been returned.

Now that we have a password, let's lock the account and see what happens to the password string in /etc/shadow as well as to the output of "passwd -s":

# passwd -l gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       LK
# grep "^gmb:" /etc/shadow
gmb:*LK*Onk28eSYhYJ8s:12683::::::

You will notice that the account was in fact locked, but what is new in Solaris 10 is that the password string is not replaced with the "*LK*" value. Instead, a "*LK*" string prefix is prepended to the password so that the original value can be kept if desired. The great thing about this is that it does not depend on the password algorithm used. With the addition of flexible crypt in Solaris 9, you can replace the default crypt algorithm with either others provided by default in Solaris or one of your own and this new locking mechanism will still just work.

To unlock a locked account, you just use the new "-u" option to the passwd(1) command:

# passwd -u gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       PS
# grep "^gmb:" /etc/shadow
gmb:Onk28eSYhYJ8s:12683::::::

The account is now unlocked and the "*LK*" prefix has been removed from the user's password string. The last thing that we will look at today is how you create a non-login account. To do this, simply use the "-N" option to the password command:

# passwd -N gmb
passwd: password information changed for gmb
# passwd -s gmb
gmb       NL
# grep "^gmb:" /etc/shadow
gmb:NP:12683::::::

You will notice that the user's original password has been removed and replaced with the string "NP". This account is now a non-login account and the original password has been discarded. You will not be able to login to this account, but the account will be able to make use of delayed execution facilities. To re-enable an account for interactive logins, simply reassign a password to the account using the passwd(1) command.

That's all for this installment. I hope you find this kind of information useful. In future installments, I will continue to highlight some of the lesser known enhancements that contribute to Solaris security in the hopes of raising awareness and their use.

Technorati Tag: OpenSolaris Solaris security

[8] Comments

• Cool info. Any ideas if there is a plan to make...

• Jason - thank you for your feedback. It is very ...

• Thanks for the info. The version of ssh I am runni...
• Did you ever find a solution for ssh?

• Jason, Patrick,

  Can you configure your versio...

• This is simply great information on such a common...

• Dale,

  Thank you very much! I am...

• Post a comment

Share and Enjoy!
Posted at 09:46PM Sep 21, 2004 by gbrunett in Solaris 10 Security Tags: nevada opensolaris security solaris