Make tmpfiles safe #8822

fbuihuu · 2018-04-26T07:15:58Z

It's an RFC as a starting point to fix #7986 completely.

Currently this makes 'f' completely safe only. If this appears to be an acceptable fix, I'll fix the rest of the operations.

keszybz · 2018-04-26T08:37:30Z

src/tmpfiles/tmpfiles.c


-        if (S_ISDIR(st->st_mode)) {
+        if (fstat(fd, &st) < 0) {
+                r = r ?: -errno;


Downgrade-to-bool is frowned upon. Better to write this as

if (r >= 0) r = -errno;

keszybz · 2018-04-26T08:39:45Z

src/tmpfiles/tmpfiles.c

+        if (r < 0)
+                return log_error_errno(r, "Failed to write file \"%s\": %m", path);
+
+        r = path_set_perms(i, path);


return path_set_perms(...)?

hmm, so we follow symlinks for writing but not for application of perms. This deserves some comment here. (because otherwise the next one looking at this, like me, might think that fd_set_perms() would be the right call to make here, rather than path_set_perms()...

keszybz · 2018-04-26T08:43:02Z

src/tmpfiles/tmpfiles.c

-        flags = O_CREAT|O_NOFOLLOW|(i->type == CREATE_FILE ? O_EXCL : O_TRUNC);
+        /* 'f' operates on regular files exclusively. */
+
+        flags = O_CREAT|O_EXCL|O_NOFOLLOW;


flags has just a single use. I'd prefer to not have the variable and just put the flags definition in open below, and add the comment there.

@fbuihuu this comnment is still not addressed...

keszybz · 2018-04-26T08:44:55Z

src/tmpfiles/tmpfiles.c

+                if (!S_ISREG(st.st_mode))
+                        return log_error_errno(EEXIST, "%s exists and is not a regular file.", path);
+
+                goto check_perms;


Maybe get rid of the goto and just put the code that is jumped over in an else { } branch?

also, here too we'll stat the file twice in the end, I think it would be much nicer to pass "struct stat" if we have it, like in this case, and only query it in fd_set_perms() if we don't.

keszybz · 2018-04-26T08:46:36Z

src/tmpfiles/tmpfiles.c

-        return 0;
+                /* On a read-only filesystem, we don't want to fail if the
+                 * target is already empty and the perms are set. So we still
+                 * proceed with the sanity checks and let fails the remaining


"and let the remaining operations fail with EROFS"

keszybz · 2018-04-26T08:49:09Z

src/tmpfiles/tmpfiles.c

+        int fd;
+
+        dn = dirname_malloc(path);
+        if (dn == NULL)


fbuihuu · 2018-04-26T11:13:50Z

@keszybz before going into the details of fixing the code, I'd like to know if the general idea is acceptable.

As described in one commit this can break compatibility in some cases as "unsafe" transitions (the definition of unsafe is given by chase_symlink(... CHASE_SAFE ...)) are not followed anymore.

Maybe we could relax a bit the security checks and consider a transition unsafe only if it's done via a symlink ?

poettering · 2018-04-26T11:59:52Z

src/tmpfiles/tmpfiles.c

@@ -769,8 +769,9 @@ static bool hardlink_vulnerable(const struct stat *st) {
        return !S_ISDIR(st->st_mode) && st->st_nlink > 1 && dangerous_hardlinks();
 }

-static int fd_set_perms(Item *i, int fd, const struct stat *st) {
+static int fd_set_perms(Item *i, int fd) {


i don't like this i must say, because this means that path_set_perms() will then effectively stat all dirs twice...

A better approach might be to accept st being passed as NULL here, and if it is, gather the data fresh, so that callers may but don't have to pass in stat initialized.

struct stat stbuf; … if (!st) { if (fstat(fd, &stbuf) < 0) return -errno; st = &stbuf; }

poettering · 2018-04-26T12:04:30Z

src/tmpfiles/tmpfiles.c

+        if (r < 0)
+                return log_error_errno(r, "Failed to write file \"%s\": %m", path);
+
+        r = path_set_perms(i, path);


hmm, so we follow symlinks for writing but not for application of perms. This deserves some comment here. (because otherwise the next one looking at this, like me, might think that fd_set_perms() would be the right call to make here, rather than path_set_perms()...

poettering · 2018-04-26T12:07:12Z

src/tmpfiles/tmpfiles.c

+                if (!S_ISREG(st.st_mode))
+                        return log_error_errno(EEXIST, "%s exists and is not a regular file.", path);
+
+                goto check_perms;


also, here too we'll stat the file twice in the end, I think it would be much nicer to pass "struct stat" if we have it, like in this case, and only query it in fd_set_perms() if we don't.

fbuihuu · 2018-04-26T12:24:01Z

hmm, so we follow symlinks for writing but not for application of perms. This deserves some comment here. (because otherwise the next one looking at this, like me, might think that fd_set_perms() would be the right call to make here, rather than path_set_perms()...

@poettering not really the goal here is to resolve and validate the path only once, therefore we want to call fd_set_perms() ultimately (as you expect) and this is done in a separate commit, which makes the function completely safe.

fbuihuu · 2018-05-23T06:57:28Z

Hi guys, I force pushed a new version. It contains more commits I accumulated over the last month to make most of the code hopefully safe.

Please have a look.

poettering · 2018-05-23T19:17:31Z

src/tmpfiles/tmpfiles.c

@@ -1528,8 +1528,7 @@ static int create_directory_or_subvolume(Item *i, const char *path) {
                        RUN_WITH_UMASK((~i->mode) & 0777)
                                r = btrfs_subvol_make(i->path);
                }
-        } else
-                r = 0;
+        }


dropping this looks like something that will trip up gcc sooner or later, as it tends to be too dumb to realize that r is always initialized in the r == -ENOTTY check in the if line immediately following...

Moreover, I'd prefer if we didn't write this code so fragile, as the order of the checks in the following if line suddenly matters, which is very much not obvious

poettering · 2018-05-23T19:18:03Z

src/tmpfiles/tmpfiles.c

@@ -1562,9 +1561,9 @@ static int create_directory_or_subvolume(Item *i, const char *path) {
                if (r == -ENOTTY)
                        log_debug_errno(r, "Couldn't adjust quota for subvolume \"%s\" (unsupported fs or dir not a subvolume): %m", i->path);
                else if (r == -EROFS)
-                        log_debug_errno(r, "Couldn't adjust quota for subvolume \"%s\" (fs is read-only).", i->path);
+                        log_debug("Couldn't adjust quota for subvolume \"%s\" (fs is read-only).", i->path);


why this change? we should always propagate error codes we get to the journal, and that's what log_debug_errno() does

poettering · 2018-05-23T19:19:39Z

hmm, before i continue with the review, did you see my earlier comment? i think the fstat() bit of it is not addressed yet, is it?

also, needs a rebase

fbuihuu · 2018-05-24T12:48:35Z

Erf sorry I forgot to reply to your comment.

So I saw your comment about fstat() but I'm not sure yet...

If you look at the end result of the patch series you'll see that only fd_set_perms() might be a concern (the other helpers doesn't need to stat the file at all).

Even in this case fstat() might be performed by 2 callers of fd_set_perms() but they're still corner cases:

in create_file(), it's only done in the error code path
in truncate_file(), the stat info might be outdated because we might truncate the file

The second case shows that if we rely (optionally) on the caller to pass the stat info, they might be outdated...

Also I think the minor simplification done in item_do() is valid but I'll split the patch so this part can be reviewed separately.

fbuihuu · 2018-05-24T12:48:55Z

Also will rebase the serie

fbuihuu · 2018-05-24T15:29:39Z

@poettering I finally followed your suggestion about fstat() as it seems useful for the recursive path.

poettering

another round. I figure the [RFC] should be dropped from the title of this PR no? and the "dont-merge", too, right? I mean, you intend to get this merged soon, right?

poettering · 2018-05-30T15:40:45Z

src/tmpfiles/tmpfiles.c


-        if (i->type == EMPTY_DIRECTORY && !S_ISDIR(st.st_mode))
-                return log_error_errno(EEXIST, "'%s' already exists and is not a directory. ", path);
+                if(!S_ISDIR(stbuf.st_mode))


coding style nitpick: space between "if" and "("

this comment has not been addressed?

poettering · 2018-05-30T15:41:23Z

src/tmpfiles/tmpfiles.c

+                st = &stbuf;
+        }
+
+


coding style nitpick: double empty line

poettering · 2018-05-30T15:45:01Z

src/tmpfiles/tmpfiles.c

+        assert(i->type == WRITE_FILE);
+
+        /* Follows symlinks */
+        fd = open(path, O_NDELAY|O_CLOEXEC|O_WRONLY|O_NOCTTY, i->mode);


hmm, we generally try to use O_NONBLOCK rather than O_NDELAY all across our codebase, since O_NDELAY is an older obsolete name... in fact we even have a coccinelle script in place that fixes that (see coccinelle/o-ndelay.cocci)

poettering · 2018-05-30T15:46:42Z

src/tmpfiles/tmpfiles.c

-        flags = O_CREAT|O_NOFOLLOW|(i->type == CREATE_FILE ? O_EXCL : O_TRUNC);
+        /* 'f' operates on regular files exclusively. */
+
+        flags = O_CREAT|O_EXCL|O_NOFOLLOW;


@fbuihuu this comnment is still not addressed...

poettering · 2018-05-30T15:48:48Z

src/tmpfiles/tmpfiles.c

+         * fifo nor a terminal device. Therefore we first open the file and make
+         * sure it's a regular one before truncating it. */
+
+        flags = O_CREAT|O_NOFOLLOW;


as above, no need to have flags as variable if we always set it to one value only...

poettering · 2018-05-30T16:38:38Z

src/tmpfiles/tmpfiles.c

+        if (r < 0)
+                return log_error_errno(r, "is_dir() failed on file %s: %m", path);
+        if (r == 0)
+                return log_error_errno(EEXIST, "'%s' already exists and is not a directory. ", path);


as mentioned earlier: don't pass EEXIST directly to log_error_errno()

also trailing whitespace in string

poettering · 2018-05-30T16:44:31Z

src/basic/fs-util.h

@@ -78,6 +78,7 @@ enum {
        CHASE_OPEN        = 1U << 4,   /* If set, return an O_PATH object to the final component */
        CHASE_TRAIL_SLASH = 1U << 5,   /* If set, any trailing slash will be preserved */
        CHASE_STEP        = 1U << 6,   /* If set, just execute a single step of the normalization */
+        CHASE_NOFOLLOW    = 1U << 7,   /* If set, don't follow the final component if it's a symlink */


hmm, this should be clarified a bit. if we have a symlink change "a → b → [non-existing]", then resolving "a" would return "a" rather than "b", hence it's final only in the sense that it is the last part of the path, not the last part of the chain

poettering · 2018-05-30T16:45:02Z

src/test/test-fs-util.c

+        assert_se(pfd > 0);
+        assert_se(path_equal(result, q));
+        assert_se(fstat(pfd, &st) >= 0);
+        assert_se(S_ISLNK(st.st_mode));


i'd prefer a test here that shows what is returned if we have a symlink chain "a → b → [non-existant]" and resolve "a"

poettering · 2018-05-30T16:45:57Z

src/tmpfiles/tmpfiles.c

+
+        fd = chase_symlinks(path, NULL, CHASE_OPEN|CHASE_SAFE|CHASE_NOFOLLOW, NULL);
+        if (fd == -EPERM)
+                log_error("Unsafe symlinks encountered in %s, aborting.", path);


errors we recieve should be passed to log_error_errno(), so that they are included in the structure log message even if we don't show them in the text msg

poettering · 2018-05-30T16:46:14Z

src/tmpfiles/tmpfiles.c

        if (fd < 0)
-                return log_error_errno(errno, "Adjusting owner and mode for %s failed: %m", path);
+                return log_error_errno(fd, "Adjusting owner and mode for %s failed: %m", path);


this means we'll now log twice about EPERM, which we really shouldn't

poettering · 2018-06-06T09:28:14Z

(btw, also need a rebase)

fbuihuu · 2018-07-02T08:51:02Z

@poettering sorry for the delay, here is a new round with hopefully your last concerns addressed.

Please have a look.

poettering · 2018-07-02T10:40:56Z

@fbuihuu still needs a rebase and the all CIs fail...

evverx · 2018-07-02T13:17:14Z

This pull request introduces 1 alert when merging f17d604 into 2479c4f - view on LGTM.com

new alerts:

1 for FIXME comment

Comment posted by LGTM.com

fbuihuu · 2018-07-02T17:11:05Z

@poettering, rebased.

poettering

so the biggie is that fd_get_path() should not be used if we can avoid it due to its ambiguity and unreliability. It's a bit hacky to use it at all, but i figure it's ok if it allows us to use openat() style apis more comprehensively, hence I am ok with it, but then at least we should not ignore the path if we have it anyway like your patch does it now

poettering · 2018-07-02T17:19:17Z

src/tmpfiles/tmpfiles.c


-        if (i->type == EMPTY_DIRECTORY && !S_ISDIR(st.st_mode))
-                return log_error_errno(EEXIST, "'%s' already exists and is not a directory. ", path);
+                if(!S_ISDIR(stbuf.st_mode))


this comment has not been addressed?

poettering · 2018-07-02T17:21:57Z

src/tmpfiles/tmpfiles.c

+        assert(path);
+
+        if (path_equal(path, "/") || !path_is_normalized(path))
+                return -EINVAL;


is there any reason not to allow the root dir here?

this means people can't use tmpfiles to let's say add an xattr on the root dir. Why prohibit that though?

Indeed, I'll remove it.

poettering · 2018-07-02T17:26:42Z

src/basic/fs-util.h

@@ -73,6 +73,7 @@ enum {
        CHASE_OPEN        = 1 << 4, /* If set, return an O_PATH object to the final component */
        CHASE_TRAIL_SLASH = 1 << 5, /* If set, any trailing slash will be preserved */
        CHASE_STEP        = 1 << 6, /* If set, just execute a single step of the normalization */
+        CHASE_NOFOLLOW    = 1 << 7, /* If set, don't follow the final component of the passed path if it's a symlink */


comment should say: "only valid with CHASE_OPEN: when the path's right-most component refers to symlink return O_PATH fd of the symlink, rather than following it"

poettering · 2018-07-02T17:34:02Z

src/tmpfiles/tmpfiles.c

+        /* FIXME: O_TRUNC is unspecified if file is neither a regular file nor a
+         * fifo nor a terminal device. Therefore we should fail if file is
+         * anything but a regular file with 'F'. */
+        flags = O_CREAT|O_NOFOLLOW|(i->type == CREATE_FILE ? O_EXCL : O_TRUNC);


hmm, it's a bit strange that some flags are set in this variable and others merged in in the open(). pick one.

The "main" flags are set here, i.e. the one which are related to the creation of the file. But I wouldn't pay too much attention for this as it's gone in the end.

poettering · 2018-07-02T17:44:31Z

src/basic/smack-util.c

-        if (fd < 0) {
-                if ((flags & LABEL_IGNORE_ENOENT) && errno == ENOENT)
-                        return 0;
+        r = fd_get_path(fd, &path);


we should use fd_get_path() only if we have to. i.e. when mac_smack_fix() is called, i.e. we know the real filename anyway, use that. fd_get_path() is problematic due the (deleted) ambiguity, and because of chroot and stuff...

poettering · 2018-07-02T17:45:16Z

src/basic/selinux-util.c

-
-                r = selabel_lookup_raw(label_hnd, &filecon, newpath, mode);
-        }
+        r = fd_get_path(fd, &path);


as for the smack stuff: please use any real path we might have if possible. fd_get_path() should be the fallback if we have nothing better, but only then

fbuihuu · 2018-07-03T09:01:44Z

@poettering thanks for your feedback, new version pushed.

evverx · 2018-07-03T09:40:45Z

This pull request introduces 1 alert when merging 55aaff8 into db2f8a2 - view on LGTM.com

new alerts:

1 for FIXME comment

Comment posted by LGTM.com

…e them safe

In this case it simply returns the random generated filename with anything prefixed.

This flag mimics what "O_NOFOLLOW|O_PATH" does for open(2) that is chase_symlinks() will not resolve the final pathname component if it's a symlink and instead will return a file descriptor referring to the symlink itself. Note: if CHASE_SAFE is also passed, no safety checking is performed on the transition done if the symlink would have been followed.

Since all path_set_*() helpers don't follow symlinks, it's possible to use chase_symlinks(CHASE_NOFOLLOW) flag to both open the files specified by the passed paths and check their validity (unlike their counterpart fd_set_*() helpers).

fbuihuu · 2018-07-30T14:09:32Z

@poettering thanks for your patience... new version forced pushed.

evverx · 2018-07-30T14:42:09Z

This pull request introduces 1 alert when merging 7f6240f into 1c57fa9 - view on LGTM.com

new alerts:

1 for FIXME comment

Comment posted by LGTM.com

fbuihuu · 2018-08-03T15:42:47Z

@poettering we're close to the end, well I hope :D

poettering · 2018-08-03T15:52:43Z

src/basic/fileio.c

+        if (isempty(p))
+                x = stpcpy(stpcpy(t, ".#"), extra);
+        else
+                x = stpcpy(stpcpy(stpcpy(t, p), "/.#"), extra);


he new() allocation further up is now a bit sloppy, as it calculates 3 instead of just 2 btyes if t is the empty string... but i figure that doesn't matter

yeah at least it makes the allocation simpler by allocating the largest size we will need.

poettering · 2018-08-03T16:05:55Z

src/basic/smack-util.c

+                return -errno;
+        }
+
+        r = fd_get_path(fd, &p);


as with the selinux code we should use 'path' as it is if it's already absolute, and use fd_get_path() only if we the path is not absolute yet

poettering · 2018-08-03T16:12:08Z

Only found the two issues above, which don't really matter I figure... I still would love to see the SMACK thing fixed, would be delighted to take a patch for that

poettering · 2018-08-03T16:12:23Z

Anyway, merged! Thanks a ton for working on this!

orlitzky · 2018-08-03T16:17:15Z

+1 this was a huge effort, thank you.

fbuihuu · 2018-08-03T16:36:38Z

Thanks @poettering for reviewing this stuff, this was a huge effort too.

I'll fix the SMACK stuff next week.

Cheers.

fbuihuu · 2018-08-06T09:33:28Z

@poettering see PR #9802 for the SMACK stuff.

anarcat · 2018-11-14T22:51:55Z

are there efforts to backport this to previous versions? i am aware of Ubuntu making some work on 229 in https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.8 - but what about older releases? I'm working on fixing security issues in Debian jessie's version (215).

fbuihuu · 2018-11-20T15:39:50Z

Given that it already requires many commits to be backported on top of v234, I wondering if it would be reasonable to backport the fix to older versions...

anarcat · 2018-11-20T18:43:28Z

On 2018-11-20 15:40:02, Franck Bui wrote: Given that it already requires many commits to be backported on top of v234, I wondering if it would be reasonable to backport the fix to older versions...

My attempts at backporting the PR have more or less failed. My next approach is to simply backport all of the current tmpfiles.c (or any better version) to v215.

fbuihuu added tmpfiles dont-merge 💣 labels Apr 26, 2018

fbuihuu mentioned this pull request Apr 26, 2018

tmpfiles: symlinks are followed in non-terminal path components (CVE-2018-6954) #7986

Closed

keszybz changed the title ~~Rfc tmpfiles safe upstream~~ [RFC] tmpfiles safe upstream Apr 26, 2018

keszybz reviewed Apr 26, 2018

View reviewed changes

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from 7fd5f41 to ae60d0c Compare April 26, 2018 12:06

poettering requested changes Apr 26, 2018

View reviewed changes

poettering requested changes May 23, 2018

View reviewed changes

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from da900da to 03d458f Compare May 24, 2018 15:27

poettering requested changes May 30, 2018

View reviewed changes

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from 03d458f to c6899e5 Compare July 2, 2018 08:48

fbuihuu changed the title ~~[RFC] tmpfiles safe upstream~~ Make tmpfiles safe Jul 2, 2018

fbuihuu removed the dont-merge 💣 label Jul 2, 2018

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from c6899e5 to f17d604 Compare July 2, 2018 12:37

poettering requested changes Jul 2, 2018

View reviewed changes

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from f17d604 to 55aaff8 Compare July 3, 2018 08:59

fbuihuu added 12 commits July 30, 2018 15:54

btrfs-util: introduce btrfs_subvol_make_fd()

62f9666

basic/stat-util: introduce is_dir_fd()

a12e4ad

tmpfiles: introduce create_directory() and create_subvolume() and mak…

4c39d89

…e them safe

tmpfiles: introduce empty_directory()

5494602

tmpfiles: introduce create_fifo()

a2fc2f8

fileio: make tempfn_random_child() accept empty string as path

43231f0

In this case it simply returns the random generated filename with anything prefixed.

fs-util: introduce mkfifoat_atomic() helper

4fe3828

tmpfiles: make create_fifo() safe

7ea5a87

tmpfiles: add more tests

9f36a8f

path-util: make use of path_join() in path_make_absolute_cwd()

7f6240f

fbuihuu force-pushed the rfc-tmpfiles-safe-upstream branch from c50da5e to 7f6240f Compare July 30, 2018 14:08

poettering reviewed Aug 3, 2018

View reviewed changes

poettering merged commit 6854990 into systemd:master Aug 3, 2018

fbuihuu deleted the rfc-tmpfiles-safe-upstream branch August 3, 2018 19:58

poettering mentioned this pull request Aug 6, 2018

various tmpfiles fixes #9809

Merged

orlitzky mentioned this pull request Aug 9, 2018

CVE-2018-21269: checkpath root privilege escalation following non-terminal symlinks OpenRC/openrc#201

Closed

Make tmpfiles safe #8822

Make tmpfiles safe #8822

Conversation

fbuihuu commented Apr 26, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbuihuu commented Apr 26, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbuihuu commented Apr 26, 2018

fbuihuu commented May 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

poettering commented May 23, 2018

fbuihuu commented May 24, 2018

fbuihuu commented May 24, 2018

fbuihuu commented May 24, 2018

poettering left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

poettering commented Jun 6, 2018

fbuihuu commented Jul 2, 2018

poettering commented Jul 2, 2018

evverx commented Jul 2, 2018

fbuihuu commented Jul 2, 2018

poettering left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fbuihuu commented Jul 3, 2018

evverx commented Jul 3, 2018

fbuihuu commented Jul 30, 2018

evverx commented Jul 30, 2018

fbuihuu commented Aug 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

poettering commented Aug 3, 2018

poettering commented Aug 3, 2018

orlitzky commented Aug 3, 2018

fbuihuu commented Aug 3, 2018

fbuihuu commented Aug 6, 2018

anarcat commented Nov 14, 2018

fbuihuu commented Nov 20, 2018

anarcat commented Nov 20, 2018 via email

fbuihuu commented Apr 26, 2018 •

edited