coupleprogramming

This report is a little late, but I’m in my exams period and had to do a lot of studying. I had three exams already and have two to go next week, so I will be back full time, after that. This report is about this and the last week, enjoy :D.

What did I do this week (and the last):
Since some “easy” ebuilds have been patched, flameeyes suggested, I could take a look at tcpdump. While tcpdump has no suid-bit set, it can only be run as root, which is inconvenient. It would be nice if “special” users could run it to sniff (without using sudo) and normal users can use it to view dumps. Then it could also be moved to /usr/bin/. So how could you realize that with caps?
There is a pam module called pam_cap, which allows you to put caps in the users inherited set.
Then there are two options:

1. Is your application capability-aware?
   You can put the caps in the permitted set and/or inherited set.
2. Is your application not capability-aware?
   You will have to put the caps in the inherited and effective set.

Only capability-aware application can populate their effective set themselves, the kernel has to do it for the others. And the kernel knows, if the effective set is not empty, the application is not capability-aware [0].

So, how do you use pam_cap?

1. You need to have libcap installed. (Obviously :))
2. You need to include pam_cap.so in your /etc/pam.d/system-auth.
   Something like this:
   auth required pam_env.so
auth required pam_cap.so
...
3. Add caps to users in /etc/security/capability.conf.
   Like this:
   #netadmin inherits cap_net_admin,cap_net_raw
cap_net_admin,cap_net_raw netadmin
#every other user inherits nothing
none *
   The last line is very important, otherwise all other users inherit all caps, which would be not what we wanted.
4. Logout/Login
5. It should work now, but maybe you need to reboot.

Now, that you can grant users certain caps, you can put the caps on your binaries in ei or p/pi instead of ep and only the users, who have the right caps in their set can execute these binaries correctly. To try it out you can emerge tcpdump from my overlay, which has cap_net_raw in its effective and inherited set. Only a user who has at least cap_net_raw in his/her set can sniff with tcpdump.

You want to see this as an example, before you try it out on your system? Here you go:
This is my /etc/pam.d/system-auth:

auth required pam_env.so
auth required pam_cap.so
auth required pam_unix.so try_first_pass likeauth nullok

account required pam_unix.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow
session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_permit.so

This is my /etc/security/capabiliy.conf

#
# /etc/security/capability.conf
#
# this is a sample capability file (to be used in conjunction with
# the pam_cap.so module)
#
# In order to use this module, it must have been linked with libcap
# and thus you’ll know about Linux’s capability support.
# [If you don't know about libcap, the sources for it are here:
#
# http://linux.kernel.org/pub/linux/libs/security/linux-privs/
#
# .]
#
# Here are some sample lines (remove the preceding ‘#’ if you want to
# use them

## user ‘morgan’ gets the CAP_SETFCAP inheritable capability
##cap_setfcap morgan

cap_net_admin,cap_net_raw netadmin

## ‘everyone else’ gets no inheritable capabilities
none *

## if there is no ‘*’ entry, all users not explicitly mentioned will
## get all available capabilities. This is a permissive default, and
## probably not what you want…

tcpdump is now in /usr/bin/, let’s look at its caps.
superkfr@totoro ~ $ sudo getcap /usr/bin/tcpdump
/usr/bin/tcpdump = cap_net_raw+ei
It has cap_net_raw in the effective and inherited set, good so far.

Let’s try to execute tcpdump with the user netadmin, who has the required caps.
superkfr@totoro ~ $ su - netadmin
Password:
netadmin@totoro ~ $ tcpdump -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
...
netadmin@totoro ~ $ exit
logout
Works just fine.

Let’s try with user test, who has no caps inherited.
superkfr@totoro ~ $ su - test
Password:
test@totoro ~ $ tcpdump -i wlan0
tcpdump: wlan0: You don't have permission to capture on that device
(socket: Operation not permitted)
test@totoro ~ $ tcpdump -r /tmp/dump
reading from file /tmp/dump, link-type EN10MB (Ethernet)
...
test@totoro ~ $ exit
logout

Like we expected, user test does not have the right permissions to sniff, but can view dumps.

If you have trouble getting pam_cap to work (believe me, I’ve been there), try this:
Look at the output of /sbin/getpcaps $$ in the shell of the user, whom you want to have the caps.

• If the output looks something like this:
  test@totoro ~ $ /sbin/getpcaps $$
Capabilities for `8219': =
  The users cap set is empty and something didn’t work. Try rebooting, if you haven’t done this already.
• If the output looks something like this:
  netadmin@totoro ~ $ /sbin/getpcaps $$
Capabilities for `13976': = cap_net_admin,cap_net_raw+i
  It worked.

So that’s it for this week. Hope to hear from you in the comments :D.

[0] http://www.linuxjournal.com/magazine/making-root-unprivileged