[Techtalk] LIDS and CAPSET woes

[Raven Alder]

Heya --

	Long and complex (but interesting, I hope) question here for the
kernel gurus and security folk.  I have recently installed the LIDS
kernel patch on a Slackware 8.1 box at work (kernel 2.4.18).  This
created many bizarre problems that I didn't expect -- today's spate of
technical ranting brought to you by the number 0x90 and the letters
fsck.  I may be giving too much history here, but I think it's relevant
to my problem.

	For those of you not so familiar with it, LIDS is a host-based
intrusion detection system.  It changes file properties and process
permissions so that even root can't monkey with them (more thoroughly
than just the immutable switch), and imposes very strict permissions on
the system by default.  So if someone was able to get a user account on
my box somehow, LIDS would make getting root from there much harder than
it normally is.  When installing LIDS, you have to give programs
permission to do things that you want them to be able to by changing the
LIDS config file (through the lidsconf command).  It's recommended to do
this *before* you reboot to your new kernel, since one of the defaults
in LIDS is "do not allow even root to change config files in /etc, or
even see the /etc/lids/lids.conf file at all".

	I had kept my old version of the kernel around as /boot/vmlinuz,
and had configured LILO to let me choose between that and my new
/boot/2.4.18-crypto-vmlinuz kernel.  I (stupidly) forgot to do the
lidsconf stuff before rebooting, because I was monkeying with the
IDE-SCSI emulation and the crypto bits too.  So I rebooted, and LIDS
wouldn't let me do anything.  XWindows wouldn't start (not allowed to
get raw-IO for the screen), my network card couldn't load its module or
request its IP through dhcpcd, nothing.  No problem, I think.  I must
just have to recompile the module again and load it.  I still have the
source for that network card driver -- cd /usr/local/src/e1000, make,
make install... oh look, LIDS won't let me write to /lib/modules.  Grah.
No problem; I'll just reboot into my LIDS-less kernel and do it there.

        Network card failed there, too.  What?  But I didn't change
anything... oh.

	Even though I had been very careful to remove the symlink
/usr/src/linux and kept /usr/src/2.4.18-virgin separate from
/usr/src/2.4.18-crypto-and-lids, I forgot that when you do the "make
modules_install" step of your kernel compile, it puts the modules in
/lib/modules/[kernelversion].  So my new LIDS-and-crypto kernel modules
had gone in /lib/modules/2.4.18, right over my old ones.  Doh.  So under
the crypto kernel, nothing worked because LIDS is very restrictive, and
under the old kernel, nothing worked because I'd overwritten all the
modules and it wasn't understanding all these calls to things that did
not exist.  So things like "insmod" failed, even when the module was
where it should be.

        Gah.  Felt very stupid indeed.  At that point, I had two choices
-- make clean, nuke everything from orbit, and build a fresh LIDSless
kernel from the virgin source, or try to make LIDS play nice.  I went
for the latter -- I did still want that protection.  *Fourteen reboots
later* (in Unix!), I have the network card working again (driver built,
but then dhcpcd wouldn't pull its IP since it needed to create
/etc/dhcpc and didn't have permission to write to /etc), XWindows will
again allow me to log in and run my programs, and I can change the LIDS
conf on the fly.  (I finally got sick of rebooting.) 

	To make all this more annoying, Slack 8.1 is really stupid when
it comes to booting into XWindows.  Rather than the five or six virtual
terminals most *nixes give you, in its default runlevel of 4 (boot into
X), Slack 8.1 just gives you the one.  So when XWindows screws up, you
have effectively no console at all.  /etc/inittab says that it gives you
another on tty1, but I was unable to get to that when kdm was failing.
Thank $deity for ssh.  Rarr.  (And I'm glad I got the network driver
back up, too.)

	I have vsftpd on the box, so that when I need it to act as an
FTP server I can fire that up and then kill the process after I've
transferred whatever files.  Pre-LIDS, this was working fine.  Now I can
start vsftpd and it seems like the daemon is running fine, but when
trying to log into it, I get this:

raven at batcat ~ $ ftp localhost
Connected to localhost.
220 (vsFTPd 1.1.3)
Name (localhost:raven): anonymous
331 Please specify the password.
Password:
500 OOPS: capset
Login failed.
ftp>

And it kicks me.  A bit of googling on the error message produces
nothing more helpful than the information that capset is something
kernel-internal.  I know that LIDS is probably responsible for this, and
if I knew what to change I could do so.  From the lids docs at
http://www.lids.org/lids-faq/LIDS-FAQ-4.html#ss4.5

                     CAP_CHOWN 0
              CAP_DAC_OVERRIDE 0
           CAP_DAC_READ_SEARCH 0
                    CAP_FOWNER 0
                    CAP_FSETID 0
                      CAP_KILL 0
                    CAP_SETGID 0
                    CAP_SETUID 0
                   CAP_SETPCAP 0
           CAP_LINUX_IMMUTABLE 0
          CAP_NET_BIND_SERVICE 0
             CAP_NET_BROADCAST 0
                 CAP_NET_ADMIN 0
                   CAP_NET_RAW 0
                  CAP_IPC_LOCK 0
                 CAP_IPC_OWNER 0
                CAP_SYS_MODULE 0
                 CAP_SYS_RAWIO 0
                CAP_SYS_CHROOT 0
                CAP_SYS_PTRACE 0
                 CAP_SYS_PACCT 0
                 CAP_SYS_ADMIN 0
                  CAP_SYS_BOOT 1
                  CAP_SYS_NICE 0
              CAP_SYS_RESOURCE 1
                  CAP_SYS_TIME 0
            CAP_SYS_TTY_CONFIG 0
                    CAP_HIDDEN 1
                 CAP_INIT_KILL 0
                   LIDS_GLOBAL 1
                               0
                   RELOAD_CONF 0
                          LIDS 0

are some of the capabilities LIDS can change.  I have nice
access-control-list-like abilities to tweak these at will, but I'm not
sure what vsftp should be needing to do.  From syslog: 

Jan  7 16:13:07 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
592 ppid 1 uid/gid (0/0) on (null tty) :  violated CAP_SYS_CHROOT 
Jan  7 16:13:07 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
592 ppid 1 uid/gid (0/0) on (null tty) : CAP_SYS_CHROOT violation:
Attempt to chroot . 
Jan  7 16:13:35 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
595 ppid 1 uid/gid (0/0) on (null tty) :  violated CAP_SYS_CHROOT  -
logging disabled for (60)s
Jan  7 16:13:35 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
595 ppid 1 uid/gid (0/0) on (null tty) : CAP_SYS_CHROOT violation:
Attempt to chroot .  - logging disabled for (60)s
Jan  7 16:25:13 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
627 ppid 1 uid/gid (0/0) on (null tty) :  violated CAP_SYS_CHROOT 
Jan  7 16:25:13 batcat kernel: LIDS: vsftpd (dev 3:3 inode 1571605) pid
627 ppid 1 uid/gid (0/0) on (null tty) : CAP_SYS_CHROOT violation:
Attempt to chroot .

	This seems to imply that giving vsftpd the ability to chroot
would do it.  But even with that added:

root at batcat /var/log $ lidsconf -A -o /usr/local/sbin/vsftpd -j READONLY        
ADD
root at batcat /var/log $ lidsconf -A -s /usr/local/sbin/vsftpd -o
CAP_SYS_CHROOT -j GRANT
ADD
root at batcat /var/log $ killall vsftpd
[1]+  Terminated              vsftpd  (wd: /usr/local/src)
(wd now: /var/log)
root at batcat /var/log $ vsftpd &
[1] 656

I still get the same error when attempting to use the FTP server.

	Can anyone explain to me in small words what CAPSET does in the
kernel, and what I might need to tell LIDS to do in order to get my FTP
server working again?  Thanks in advance (and for reading this whole
tale of woe).

Cheers,
Raven

"Mug the Traveller."
  -- advice from the box of an Irish tea cup