OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: sysloggers (was: Re: [RFC] environment sanitisation wrapper)
From: Jim Dennis (jimdstarshine.org)
Date: Thu Jun 08 2000 - 13:32:27 CDT

Apparently "Francis A. Holop" <fredfrancis.unitra.sk> wrote:

> hmm, Kurt Seifried said that
 
>> secure-syslog
>> The major problem with syslog however is that tampering with log files is
>> trivial (setting the log files append only with "chattr +a" helps, but if an
                                                 ^^^^^^^^^^^^^^
> some systems like OpenBSD on certain security levels do not allow
> changing these attributes... you must go into single mode before
> the change.
 

 Linux 2.0 had "securelevel" features (which could raise via
 'echo $newlevel > /proc/.../securelevel'). 2.2 dropped those
 in preference for the "capabilities" (privilege bits) features,
 and 2.3 (2.4-to-be) introduces a "capabilities bounding set"
 which was supposed to make it possible to easily emulate
 securelevel (by setting a mask on the global allowed set of
 caps).

 However, the list of capabilities is a hopeless mess for
 some of what we want to do. Luckily we can lock out changes
 to the "immutability" attribute (though I'm not sure if that
 includes the "append-only" attr). However there is one giant
 "CAP_SYS_PACCT" bit that controls a mess of different features
 that make it too powerful for some operations and just what
 one needs for some other ones.

 Here's an excerpt from /usr/src/linux/include/linux/capability.h:

#define CAP_SYS_PACCT 20

/* Allow configuration of the secure attention key */
/* Allow administration of the random device */
/* Allow examination and configuration of disk quotas */
/* Allow configuring the kernel's syslog (printk behaviour) */
/* Allow setting the domainname */
/* Allow setting the hostname */

/******** jtd: ARGH! ********/

/* Allow calling bdflush() */
/* Allow mount() and umount(), setting up new smb connection */

/******** jtd: ARGH! ********/

/* Allow some autofs root ioctls */
/* Allow nfsservctl */
/* Allow VM86_REQUEST_IRQ */
/* Allow to read/write pci config on alpha */
/* Allow irix_prctl on mips (setstacksize) */
/* Allow flushing all cache on m68k (sys_cacheflush) */
/* Allow removing semaphores */
/* Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores
   and shared memory */
/* Allow locking/unlocking of shared memory segment */
/* Allow turning swap on/off */
/* Allow forged pids on socket credentials passing */
/* Allow setting readahead and flushing buffers on block devices */
/* Allow setting geometry in floppy driver */
/* Allow turning DMA on/off in xd driver */
/* Allow administration of md devices (mostly the above, but some
   extra ioctls) */
/* Allow tuning the ide driver */
/* Allow access to the nvram device */
/* Allow administration of apm_bios, serial and bttv (TV) device */
/* Allow manufacturer commands in isdn CAPI support driver */
/* Allow reading non-standardized portions of pci configuration space */
/* Allow DDI debug ioctl on sbpcd driver */
/* Allow setting up serial ports */
/* Allow sending raw qic-117 commands */
/* Allow enabling/disabling tagged queuing on SCSI controllers and sending
   arbitrary SCSI commands */
/* Allow setting encryption key on loopback filesystem */

 I've added a couple of comments of the form: /******** ..... ********/
 and some whitespace to highlight the worst problem I see with
 this bit.

 If I read that correctly you need this bit to force the block caches
 to flush and to call the mount/umount commands. So I can't remove
 this bit from the system (to prevent remounting my ro filesystem in
 rw mode) and still allow a bdflush daemon to be started normally.
 I guess I'd have to write some code to grant that priv to the
 bdflush daemon from init or from the process that is setting this
 cap bounding set.

 I still think that the cap/privs model is a mire from which we'll
 never get any useful improvements in overall system security but
 in which we will ultimately waste alot of time, programmer and
 sysadmin effort. Of course I argued this on the kernel list along
 time ago --- but, since I'm not a programmer and not a kernel
 hacker my opinion doesn't count for much there.

 I'd like to see Linux implement a subsystem modeled on "true"
 capabilities (like EROS: http://www.eros-os.org). Then we could
 implement a number of the "least privilege" deamons (like xntpd,
 syslogd/klogd, bdflush, apmd, cardmgr, gpm, snmpd etc) under
 that subsystem. Granted the EROS programming model is completely
 un-UNIX-like. So it wouldn't support more general purpose
 programs like login/xdm/inetd/init etc.

 The problem with "privs" is that the granularity will never be
 right. Andrew Morgan told me that he didn't want to lump all these
 "features" into PACCT, but that Linus over-rode him and demanded
 that they have less than 32 defined caps. Even if that restriction
 was raised to 64 or 128 we'd still find enough things that
 shouldn't be "lumped" together and a rate of complexity increase
 that would ultimately REDUCE our security rather than improve it.

 In summary, Linux does have some of the "securelevel" features that
 we see in the BSD's. It's not an exact match, it hasn't been used
 to any signfication degree and therefore is not tested in
 deployment. It's possible to add more kernel restrictions using
 LIDS, and other custom patches or to implement kernel restrictions
 through the simple expedient of maintaining two kernels on your
 system (one that you use for maintenance, another with many
 features disabled that you use for "production/server" mode).

 Unfortunately there have also historically been flaws in the
 BSD securelevel implementations. Perhaps they have *all* been
 fixed now. I don't know of any good studies on the number of
 attacks that have been prevented by or more quickly detected
 due to the securelevel features. (Most of these features
 don't prevent process subversion, they don't stop someone
 from "getting root" --- they are just attempts to limit the
 scope and persistance of the compromise).

  

--
Jim Dennis         Technical Research Analyst            Linuxcare, Inc.
           jdennislinuxcare.com, http://www.linuxcare.com/
             415 740-4521                415 701-7457 fax
                 Linuxcare: Support for the Revolution