linux-kernel - Opinions on open/exec syscalls and security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4DAD361D.1010602@halfdog.net>
Date:	Tue, 19 Apr 2011 07:13:33 +0000
From:	halfdog <me@...fdog.net>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Opinions on open/exec syscalls and security

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello List,

Quite a few programs, that have to traverse directory trees recursively,
do not treat symlinks correctly, e.g. most backup applications I tested
allowed inclusion of arbitrary files. Although this could just be seen
as a problem of application security, I think that the suboptimal kernel
interface to filesystem makes it hard to code correctly, hence
increasing the number of vulnerable programs of some type (e.g. backup
programs).

The problem is, that is hard to open a file in a user-controlled
directory, e.g. for backup, and apply some policy to that, e.g. that no
component in the path is a symlink. Otherwise, the sequence

readdir /home/user/somedir/
open  /home/user/somedir/shadow

in a backup program might cause inclusion of real password, if somedir
was moved and relinked to /etc in between the two calls, a race that is
very easy to win. If the backup program would do only openat/stat pairs
for every component in the path, the program then might run out of
filedescriptors easily (DOS).

- From my opinion, the system api, that makes it too hard to check, if
problematic symlinks (or user space filesystem mounts) are included in a
path. To provide really time-race free api, an open-and-check operation
could be useful. An implementation of a "secure" file open library call,
e.g. in libc, would also be an option, but it might be rather hard to
provide the same level of security, because the library routine has no
atomic syscall to rely on, and hence implementation might be racy,
altough the window of opportunity might be very small. Without this
system support, it is quite tricky to write 100% correct code and one
might introduce other flaws, e.g. DOS via reaching max. open file
descriptors.

Could a new syscall or modified syscall options make it easier for
developers, so that they to not have to keep numerous fds open and apply
all the policy checks in user space, e.g. using inode numbers, dev
references?

See http://www.halfdog.net/Security/2010/FilesystemRecursionAndSymlinks/
for a short writeup on that topic (still work in progress).

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFNrTVdxFmThv7tq+4RAprNAJ9nTTy2s2zjS4zy6wUk7SZPkN10nwCgh061
mNiOTFp9x0mhvkA418AHDgo=
=6LcN
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/