Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

setfiles: rootpath logic breaks on absolute symlinks #248

Closed
lucab opened this issue Jun 3, 2020 · 3 comments
Closed

setfiles: rootpath logic breaks on absolute symlinks #248

lucab opened this issue Jun 3, 2020 · 3 comments

Comments

@lucab
Copy link

lucab commented Jun 3, 2020

This is a followup from coreos/fedora-coreos-tracker#512.

This affects the latest released version, as packaged in Fedora (package NEVRA is policycoreutils-3.0-2.module_f32+7989+651e8914.x86_64).

When using the -r logic to relabel files under a different rootpath, symlinks to absolute paths seem to break the relabeling logic:

# mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
# echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

However, from the point of view of the new rootpath, paths and symlinks are setup properly:

# cp -a --preserve=context /usr/local/bin/busybox-sh /root/my-chroot/
# chroot /root/my-chroot/ /busybox-sh cat /symlink
foo

So this sounds like a bug in setfiles relabeling logic.
@lucab lucab mentioned this issue Jun 3, 2020
Closed
@stephensmalley
Copy link
Member

Regression introduced by e016502

@jlebon
Copy link
Contributor

jlebon commented Jun 4, 2020

Related: https://lore.kernel.org/selinux/20200604191240.263819-1-jlebon@redhat.com/T/#u

stephensmalley added a commit to stephensmalley/selinux that referenced this issue Jun 4, 2020
@stephensmalley
libselinux: fix selinux_restorecon() statfs bug
5d3af1a 
As reported in SELinuxProject#248,
setfiles -r (rootpath) fails when the alternate root contains a symlink
that is correct relative to the alternate root but not in the current root.
This is a regression introduced by commit e016502 ("libselinux: Save
digest of all partial matches for directory").  Do not call statfs(2) here
if acting on a symbolic link.  Unfortunately there is no lstatfs() call.
Ensure that we initialize the statfs buffer always.  If the supplied
file is a symlink, then we don't need to worry about the later tests of
filesystem type because we wouldn't be setting the digest anyway and
we are not performing a full sysfs relabel.  While here, fix the earlier
test for a directory to use the correct test.

Reproducer:
$ mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
$ echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts

Before:
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

After:
Relabeled /root/my-chroot/symlink from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:default_t:s0

Fixes: SELinuxProject#248
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
@stephensmalley
Copy link
Member

Possible fix: https://lore.kernel.org/selinux/20200604200831.28866-1-stephen.smalley.work@gmail.com/T/#u

stephensmalley pushed a commit to stephensmalley/selinux that referenced this issue Jun 9, 2020
@jlebon @stephensmalley
setfiles: clarify documented path resolution behaviour
adc2a32 
One thing that confused me when investigating
SELinuxProject#248 (i.e.
coreos/fedora-coreos-tracker#512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.

But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.

Clarify the man pages to explain this.
bachradsusi pushed a commit to bachradsusi/SELinuxProject-selinux that referenced this issue Jun 11, 2020
@stephensmalley @bachradsusi
libselinux: fix selinux_restorecon() statfs bug
7fdbd43 
As reported in SELinuxProject#248,
setfiles -r (rootpath) fails when the alternate root contains a symlink
that is correct relative to the alternate root but not in the current root.
This is a regression introduced by commit e016502 ("libselinux: Save
digest of all partial matches for directory").  Do not call statfs(2) here
if acting on a symbolic link.  Unfortunately there is no lstatfs() call.
Ensure that we initialize the statfs buffer always.  If the supplied
file is a symlink, then we don't need to worry about the later tests of
filesystem type because we wouldn't be setting the digest anyway and
we are not performing a full sysfs relabel.  While here, fix the earlier
test for a directory to use the correct test.

Reproducer:
$ mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
$ echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts

Before:
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

After:
Relabeled /root/my-chroot/symlink from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:default_t:s0

Fixes: SELinuxProject#248
Fixes: e016502 ("libselinux: Save digest of all partial matches for directory")
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
bachradsusi pushed a commit to bachradsusi/SELinuxProject-selinux that referenced this issue Jun 11, 2020
@stephensmalley @bachradsusi
libselinux: fix selinux_restorecon() statfs bug
f790cfb 
As reported in SELinuxProject#248,
setfiles -r (rootpath) fails when the alternate root contains a symlink
that is correct relative to the alternate root but not in the current root.
This is a regression introduced by commit e016502 ("libselinux: Save
digest of all partial matches for directory").  Do not call statfs(2) here
if acting on a symbolic link.  Unfortunately there is no lstatfs() call.
Ensure that we initialize the statfs buffer always.  If the supplied
file is a symlink, then we don't need to worry about the later tests of
filesystem type because we wouldn't be setting the digest anyway and
we are not performing a full sysfs relabel.  While here, fix the earlier
test for a directory to use the correct test.

Reproducer:
$ mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
$ echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts

Before:
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

After:
Relabeled /root/my-chroot/symlink from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:default_t:s0

Fixes: SELinuxProject#248
Fixes: e016502 ("libselinux: Save digest of all partial matches for directory")
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
stephensmalley pushed a commit that referenced this issue Jun 25, 2020
@jlebon @stephensmalley
setfiles: clarify documented path resolution behaviour
5f844b6 
One thing that confused me when investigating
#248 (i.e.
coreos/fedora-coreos-tracker#512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.

But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.

Clarify the man pages to explain this.

Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
bachradsusi pushed a commit to fedora-selinux/selinux that referenced this issue Jul 27, 2020
@stephensmalley @bachradsusi
libselinux: fix selinux_restorecon() statfs bug
8d82074 
As reported in SELinuxProject/selinux#248,
setfiles -r (rootpath) fails when the alternate root contains a symlink
that is correct relative to the alternate root but not in the current root.
This is a regression introduced by commit e016502 ("libselinux: Save
digest of all partial matches for directory").  Do not call statfs(2) here
if acting on a symbolic link.  Unfortunately there is no lstatfs() call.
Ensure that we initialize the statfs buffer always.  If the supplied
file is a symlink, then we don't need to worry about the later tests of
filesystem type because we wouldn't be setting the digest anyway and
we are not performing a full sysfs relabel.  While here, fix the earlier
test for a directory to use the correct test.

Reproducer:
$ mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
$ echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts

Before:
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

After:
Relabeled /root/my-chroot/symlink from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:default_t:s0

Fixes: SELinuxProject/selinux#248
Fixes: e016502 ("libselinux: Save digest of all partial matches for directory")
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
bachradsusi pushed a commit to fedora-selinux/selinux that referenced this issue Jul 27, 2020
@jlebon @bachradsusi
setfiles: clarify documented path resolution behaviour
9448e97 
One thing that confused me when investigating
SELinuxProject/selinux#248 (i.e.
coreos/fedora-coreos-tracker#512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.

But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.

Clarify the man pages to explain this.

Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
chenyt9 pushed a commit to MotorolaMobilityLLC/external-selinux that referenced this issue Mar 6, 2023
@stephensmalley @bachradsusi
libselinux: fix selinux_restorecon() statfs bug
9649acf 
As reported in SELinuxProject/selinux#248,
setfiles -r (rootpath) fails when the alternate root contains a symlink
that is correct relative to the alternate root but not in the current root.
This is a regression introduced by commit e016502 ("libselinux: Save
digest of all partial matches for directory").  Do not call statfs(2) here
if acting on a symbolic link.  Unfortunately there is no lstatfs() call.
Ensure that we initialize the statfs buffer always.  If the supplied
file is a symlink, then we don't need to worry about the later tests of
filesystem type because we wouldn't be setting the digest anyway and
we are not performing a full sysfs relabel.  While here, fix the earlier
test for a directory to use the correct test.

Reproducer:
$ mkdir /root/my-chroot && echo foo > /root/my-chroot/link-target && ln -s /link-target /root/my-chroot/symlink
$ echo "/root/my-chroot/symlink" | setfiles -vFi -r /root/my-chroot -f - /etc/selinux/targeted/contexts/files/file_contexts

Before:
setfiles: statfs(/root/my-chroot/symlink) failed: No such file or directory

After:
Relabeled /root/my-chroot/symlink from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:default_t:s0

Fixes: SELinuxProject/selinux#248
Fixes: e016502 ("libselinux: Save digest of all partial matches for directory")
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
chenyt9 pushed a commit to MotorolaMobilityLLC/external-selinux that referenced this issue Mar 6, 2023
@jlebon @stephensmalley
setfiles: clarify documented path resolution behaviour
d7e2067 
One thing that confused me when investigating
SELinuxProject/selinux#248 (i.e.
coreos/fedora-coreos-tracker#512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.

But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.

Clarify the man pages to explain this.

Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lucab @stephensmalley @jlebon