Linux file locking mechanisms - Mandatory Locking

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  23-June-2003                                                    |
|  http://www.hackinglinuxexposed.com/articles/20030623.html       |
+------------------------------------------------------------------+

This issue sponsored by EFF: Defending Freedom in the Digital World

The Electronic Frontier Foundation (EFF) is a membeship organization
that needs your help. EFF works to protect civil liberties taht
relate to new technologies. Our lawyers engage in cases that champion
online freedoms, our site archive is a comprehensive digital rights
resource, and we've developed a powerful media presence.

Check out http://www.eff.org/ to learn more.

--------------------------------------------------------------------

Linux file locking mechanisms - Mandatory Locking
By Brian Hatch

Summary: Mandatory Locking can enforce file locks at the kernel
level.

Last week I described three locking functions - flock, lockf, and
fcntl. These functions, while managed by the Linux kernel, are known
as advisory locking mechanisms. Any program which doesn't bother
checking to see if a lock is in place will never know. The kernel
won't stop it from reading or writing the file.

This can be a problem when some programs correctly wait for an
exclusive lock on a file, but other programs out of your control
access the same files simultaneously without lock checks. If you
don't have the code, it may be difficult or impossible to wrap some
sort of external locking mechanism around the closed source program.

In these cases, you can enforce locking at the kernel level with
mandatory locks. Mandatory locking is implemented on a file-by-file
basis. When a program attempts to lock a file with lockf or fcntl
that has mandatory locking set, the kernel will prevent all other
programs from accessing the file.[1] Processes which use flock will 
not trigger a mandatory lock.

To enable mandatory locking, you must first mount the filesystem with
the mand mount option:

  # mount | grep /data
  /dev/hda7 on /data type ext3 (rw,noatime)

  # mount -oremount,mand /boot
  
  # mount | grep /data
  /dev/hda7 on /data type ext3 (rw,mand,noatime)

Here I remounted the /data directory with the mand option. (I should
add mand to the appropriate /etc/fstab entry to have this setting
survive reboots as well.)

To prevent mandatory locking from taking over the entire filesystem,
only specifically tagged files will exhibit mandatory locks. The way
you define a file to be governed by mandatory locks is to set the
sgid (setgroupid) bit, but not the group execute bit. This
combination doesn't make any sense normally,[2] which is why it was
chosen for this purpose.

So, say we needed to enforce mandatory locking on the files d_* in a
directory, we'd do the following:

  $ cd /data
  $ ls -l
  -rw-r--r--    1 dbrand   stuff       82756 May 28 14:07 a_5772.dat
  -rw-r--r--    1 dbrand   stuff        7788 May 28 14:07 a_9298.dat
  -rw-r--r--    1 dbrand   stuff        3325 May 28 14:07 d_0283.dat
  -rw-r--r--    1 dbrand   stuff       19288 May 28 14:07 d_5755.dat
  -rw-r--r--    1 dbrand   stuff        1224 May 28 14:07 d_5758.dat
  
  $ chmod g+s,g-x d*
  $ ls -l
  -rw-r--r--    1 dbrand   stuff       82756 May 28 14:07 a_5772.dat
  -rw-r--r--    1 dbrand   stuff        7788 May 28 14:07 a_9298.dat
  -rw-r-Sr--    1 dbrand   stuff        3325 May 28 14:07 d_0283.dat
  -rw-r-Sr--    1 dbrand   stuff       19288 May 28 14:07 d_5755.dat
  -rw-r-Sr--    1 dbrand   stuff        1224 May 28 14:07 d_5758.dat

Henceforth, the d_* files will exhibit mandatory locking. The capital
"S" in the output signifies that the sgid bit is set, but there is no
underlying execute ("x") bit, which is what we need.

Mandatory locks should only be used where you have problem software
you cannot modify to use locks correctly. Even with mandatory locks,
you can still have conflicts. If program A reads in a file, program B
locks, edits, and unlocks the file, and program A then writes out
what it originally read, you're still in a pickle. However in many
cases, mandatory locking can help prevent corruption of your data.

The other potential problem with mandatory locks is that nothing, not
even root-owned processes, can override the lock. The best root could
do would be to kill the process that has the lock on the file. This
could be particularly nasty if the mandatory-locked file is available
via NFS or other remotely-accessible filesystem, as the entire
fileserver process itself will block until the lock is released.

NOTES:

[1] To be exact, if a program has a read or shared lock on a file, no
other program can write to it. If a program has a write or exclusive
lock on a file, no other programs can read or write to it.

[2] The sgid bit is put on programs that should run with different
group permissions than the invoking user. When a program doesn't have
the group execute bit set, this situation is rather meaningless

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He likes to periodically
delete /etc/passwd and /etc/shadow and reboot as the ultimate Linux
locking system. Brian can be reached at
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.