[Techtalk] LIDS and CAPSET woes
Mandi
mandi at linuxchick.org
Tue Jan 7 18:52:19 EST 2003
(disclaimer: i am not a kernel hacker...where's VAL when you need her?!?)
Raven --
CAPSET capset(2) is a call into the system to activate certain
kernel-level capabilities.
CAP_SYS_CHROOT is one of them. there are others. they're in
include/linux/capability.h under your kernel source. other highlights are
stuff like CAP_MKNOD, CAP_SYS_PTRACE, and on and on. They are related to
the POSIX compatibility of the kernel, and include stuff relating to
security permissions on the system at the kernel level.
your ftp server is calling in for something and not allowed to have it.
I'm not familiar with LIDS or your ftpd daemon, but you might try hooking
the PTRACE capability into it and trying to find what it's dying on that
way. It's probably something basic it assumes the ability to have.
there is one call to capset, in sysdeputil.c in the vsftpd source. It
looks like it's calling for CAP_CHOWN and CAP_NET_BIND_SERVICE. chown is
probably the one you don't have in your LIDS conf. i'm assuming this
configuration works; enGarde linux puts it together this way, i
believe...you might get some info from their site as well.
(oh, and btw, next time you build your kernel, you can change the
EXTRAVERSION in the Makefile so as not to overwrite your working system.
;) )
HTH!
--mandi
On Tue, 7 Jan 2003, Raven Alder wrote:
> 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
> _______________________________________________
> Techtalk mailing list
> Techtalk at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/techtalk
>
More information about the Techtalk
mailing list