Re: [systemd-devel] SELinux type transition rule not working
On Fri, 2017-03-03 at 09:36 -0600, Ian Pilcher wrote: > On 03/02/2017 12:12 AM, Jason Zaman wrote: > > > > On Wed, Mar 01, 2017 at 05:51:01PM -0600, Ian Pilcher wrote: > > > > > > On 03/01/2017 05:28 PM, Ian Pilcher wrote: > > > > > > > > Per Lennart's response, systemd *should* be honoring the file > > > > context > > > > rules when creating the directory. It's almost as if the > > > > directory is > > > > being created with the proper context, but something is > > > > changing it > > > > after the fact. I have absolutely no idea what that might be, > > > > though. > > > > Try using auditd to get details on everything going on in there: > > auditctl -w /var/run/squoxy -p rwa -k watchsquoxy > > > > then start things up and get everything matching with: > > ausearch -k watchsquoxy > > And wouldn't you know ... I can't reproduce the behavior > now. Sheesh! > Must be one of these fancy new quantum computers. (Something about > rebooting 3 times comes to mind.) > > > > > also, not sure if it was just weirdness in your email formatting, > > but > > you dont need the ^ at the front of an fcontext: > > ^/var/run/squoxy > > Does SELinux add an implicit ^ at the beginning of each expression? > Otherwise, wouldn't /run/squoxy(/.*)? also match > /foo/run/squoxy? (Not > necessarily likely, but ...) SELinux implicitly anchors the regexes at both ends (^regex$). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On 02/20/2014 10:42 AM, Colin Walters wrote: Currently on at least Fedora, SELinux policy does not come in the initramfs. systemd will attempt to load *both* in the initramfs and in the real root. Now, the selinux_init_load_policy() API has a regular error return value, as well as an enforcing boolean. To determine enforcing state, it looks for /etc/selinux/config as well as the presence of enforcing= on the kernel command line. Ordinarily, neither of those exist in the initramfs, so it will return unknown for enforcing, and systemd will simply ignore the failure to load policy. Then later after we switch to the real root, we have the config file, and all will work properly. Except...this all blows up if someone explicitly specifies enforcing=1 on the kernel command line. Then systemd will fail to load the nonexistent policy in the initramfs and freeze. What this patch does is quite simple - we add an internal API that says where we expect to find policy, and attempt to load it exactly from there. Right now since I'm not aware of anyone who does policy-in-initramfs, this function is hardcoded to return false. Lots-of-very-painful-debugging-by: Colin Walters walt...@verbum.org --- src/core/main.c | 6 -- src/core/selinux-setup.c | 10 ++ src/core/selinux-setup.h | 2 ++ 3 files changed, 16 insertions(+), 2 deletions(-) Wouldn't it be better (and more correct) to probe both the initramfs and the real root, and if neither one can load policy successfully and enforcing=1, then halt? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root
On 02/20/2014 01:17 PM, Colin Walters wrote: On Thu, Feb 20, 2014 at 1:06 PM, Stephen Smalley s...@tycho.nsa.gov wrote: Wouldn't it be better (and more correct) to probe both the initramfs and the real root, and if neither one can load policy successfully and enforcing=1, then halt? So you're saying we should handle -ENOENT specially in the initramfs? Something like being sure we preserve errno and returning it to the caller of selinux_init_load_policy()? That would introduce a subtle version dependency. Or alternatively, just try in the initramfs, ignore any errors, and only abort if we also fail to load in the real root? I think both of these (particularly the second) are worse than my patch - we don't (to my knowledge) support putting policy in the initramfs now with Fedora or Red Hat Enterprise Linux, so attempting to find it there by default on every bootup is wrong. To turn it around, what is the possible value in also probing the initramfs? Does anyone out there load policy from it with systemd? Ok, I guess when you put it that way... The only cases I know of where policy is loaded from initramfs are embedded Linux and Android, neither of which are using systemd to my knowledge, and both of which have custom policy loading logic anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
On Wed, 2011-05-11 at 16:27 +0200, Kay Sievers wrote: On Wed, May 11, 2011 at 15:54, Greg KH g...@kroah.com wrote: On Wed, May 11, 2011 at 01:22:42PM +0200, John Johansen wrote: On 05/11/2011 03:59 AM, Greg KH wrote: On Tue, May 10, 2011 at 03:55:24PM -0700, Casey Schaufler wrote: On 5/10/2011 3:34 PM, Greg KH wrote: From: Greg Kroah-Hartman gre...@suse.de In the interest of keeping userspace from having to create new root filesystems all the time, let's follow the lead of the other in-kernel filesystems and provide a proper mount point for it in sysfs. For selinuxfs, this mount point should be in /sys/fs/selinux/ It seems that we might want this to be an LSM interface standard. Is the call to kobject_create_and_add and associated cleanup all that's required? I would want Smack to follow the convention as well. You could always just create a subdir under /sys/security/ if you have your own filesystem, but I don't think that Smack has one, right? Is it going to get one? If so, we might want to revisit the idea of securityfs if no one is actually using it... resending, as this looks to have been lost AppArmor, IMA, and TOMOYO are using securityfs currently. Great, then it will not go anywhere. Just to get an idea how all this fits together. How can TPM bios and IMA/AppArmor share this directory? They have their own subdirs in there, or both just use the securityfs infrastructure and not their own filesystem on top? They create their own subdirs under /sys/kernel/security. tpm0, ima, apparmor, etc. They create nodes in securityfs rather than implementing their own pseudo filesystem type. -- Stephen Smalley National Security Agency ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
On Wed, 2011-05-11 at 10:58 -0400, Eric Paris wrote: On Wed, May 11, 2011 at 10:54 AM, John Johansen john.johan...@canonical.com wrote: On 05/11/2011 04:52 PM, Kay Sievers wrote: On Wed, May 11, 2011 at 16:43, Greg KH g...@kroah.com wrote: On Wed, May 11, 2011 at 04:27:59PM +0200, Kay Sievers wrote: On Wed, May 11, 2011 at 15:54, Greg KH g...@kroah.com wrote: On Wed, May 11, 2011 at 01:22:42PM +0200, John Johansen wrote: On 05/11/2011 03:59 AM, Greg KH wrote: On Tue, May 10, 2011 at 03:55:24PM -0700, Casey Schaufler wrote: On 5/10/2011 3:34 PM, Greg KH wrote: From: Greg Kroah-Hartman gre...@suse.de In the interest of keeping userspace from having to create new root filesystems all the time, let's follow the lead of the other in-kernel filesystems and provide a proper mount point for it in sysfs. For selinuxfs, this mount point should be in /sys/fs/selinux/ It seems that we might want this to be an LSM interface standard. Is the call to kobject_create_and_add and associated cleanup all that's required? I would want Smack to follow the convention as well. You could always just create a subdir under /sys/security/ if you have your own filesystem, but I don't think that Smack has one, right? Is it going to get one? If so, we might want to revisit the idea of securityfs if no one is actually using it... resending, as this looks to have been lost AppArmor, IMA, and TOMOYO are using securityfs currently. Great, then it will not go anywhere. Just to get an idea how all this fits together. How can TPM bios and IMA/AppArmor share this directory? They have their own subdirs in there, or both just use the securityfs infrastructure and not their own filesystem on top? Only one security module is allowed to be loaded/active at any one point in time, so they can't step on each other. Right, but what I don't understand is CONFIG_TCG_TPM, which seem to use securityfs, and is not a LSM. This and AppArmor/IMA can be used at the same time, can't it? They share securityfs then? AppArmor, Tomoyo and IMA all create their own subdirectoy under securityfs so this should not be a problem I guess the question is, should SELinux try to move to /sys/fs/selinux or /sys/security/selinux. The only minor issue I see with the later is that it requires both sysfs and securityfs to be mounted before you can mount selinuxfs, whereas the first only requires sysfs. Stephen, Casey, either of you have thoughts on the matter? Unless we plan to re-implement selinuxfs as securityfs nodes, I don't see why we'd move to /sys/security/selinux; we don't presently depend on securityfs and it isn't commonly mounted today. selinuxfs has some specialized functionality that may not be trivial to reimplement via securityfs, and there was concern about userspace compatibility breakage when last we considered using securityfs. -- Stephen Smalley National Security Agency ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
On Wed, 2011-05-11 at 08:13 -0700, Greg KH wrote: On Wed, May 11, 2011 at 10:54:38AM -0400, Stephen Smalley wrote: On Wed, 2011-05-11 at 16:27 +0200, Kay Sievers wrote: Just to get an idea how all this fits together. How can TPM bios and IMA/AppArmor share this directory? They have their own subdirs in there, or both just use the securityfs infrastructure and not their own filesystem on top? They create their own subdirs under /sys/kernel/security. tpm0, ima, apparmor, etc. They create nodes in securityfs rather than implementing their own pseudo filesystem type. Then I have to ask, why is selinuxfs different here? Does securityfs not provide you the api you needed to implement selinuxfs on top of it without haveing to be a separate filesystem? selinuxfs was merged into mainline in 2003 and included in Linux 2.6.0. securityfs was merged in 2005, well after selinuxfs was already shipping in distros and userspace was relying on existence of selinuxfs in /proc/filesystems as an indicator of whether or not SELinux is enabled. So we're different in part due to history and in part for the sake of preserving userspace compatibility. Even aside from that, I think there are various aspects of selinuxfs functionality that would need new interfaces from securityfs to support, although I can't say that I've looked deeply into it. Assigning specific inode numbers to specific inodes so that we can mask out an index for use within the operations, supporting transaction based I/O methods, fine-grained labeling of certain inodes (e.g. booleans), mmap support for /selinux/policy and /selinux/status, etc. -- Stephen Smalley National Security Agency ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SELINUX: add /sys/fs/selinux mount point to put selinuxfs
On Fri, 2011-04-29 at 18:19 -0700, Greg KH wrote:
From: Greg Kroah-Hartman gre...@suse.de
In the interest of keeping userspace from having to create new root
filesystems all the time, let's follow the lead of the other in-kernel
filesystems and provide a proper mount point for it in sysfs.
For selinuxfs, this mount point should be in /sys/fs/selinux/
Cc: Stephen Smalley s...@tycho.nsa.gov
Cc: James Morris jmor...@namei.org
Cc: Eric Paris epa...@parisplace.org
Cc: Lennart Poettering mzerq...@0pointer.de
Cc: Daniel J Walsh dwa...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
Note, patch is untested, I don't have any selinux-based machines here,
sorry.
If I understand correctly, the patch won't change any userspace-visible
behavior until one has a new libselinux that actually mounts selinuxfs
on /sys/fs/selinux instead of /selinux, right?
At that point, we have to ensure that all userspace that directly
references /selinux rather than using libselinux is changed to use
libselinux. You might argue that all such userspace is broken already,
but given that selinuxfs has been mounted on /selinux ever since SELinux
went into mainline in 2003 and , it is difficult to blame them. Using
codesearch.google.com on
e.g. /selinux/enforce, /selinux/load, /selinux/booleans, /selinux/mls,
etc turns up a number of examples, including glibc (a test case),
puppet, dracut, anaconda, etc.
Policy implication: Any program that needs to access selinuxfs will
need to be able to search sysfs too.
Added dependency: Any system that uses SELinux will need to enable and
mount sysfs (or alternatively create at least a fake /sys/fs directory).
I assume that sysfs is fairly universal at this point though, like proc?
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index ea39cb7..2381c16 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -1897,6 +1897,7 @@ static struct file_system_type sel_fs_type = {
};
struct vfsmount *selinuxfs_mount;
+static struct kobject *selinuxfs_kobj;
static int __init init_sel_fs(void)
{
@@ -1904,9 +1905,16 @@ static int __init init_sel_fs(void)
if (!selinux_enabled)
return 0;
+
+ selinux_kobj = kobject_create_and_add(selinux, fs_kobj);
+ if (!selinux_kobj)
+ return -ENOMEM;
+
err = register_filesystem(sel_fs_type);
- if (err)
+ if (err) {
+ kobject_put(selinux_kobj);
return err;
+ }
selinuxfs_mount = kern_mount(sel_fs_type);
if (IS_ERR(selinuxfs_mount)) {
@@ -1923,6 +1931,7 @@ __initcall(init_sel_fs);
#ifdef CONFIG_SECURITY_SELINUX_DISABLE
void exit_sel_fs(void)
{
+ kobjext_put(selinux_kobj);
unregister_filesystem(sel_fs_type);
}
#endif
--
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Stephen Smalley
National Security Agency
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. I guess I missed some discussion of this. You'd need to update libselinux at least, definition of SELINUXMNT in libselinux/src/policy.h, used by selinux_init_load_policy() to mount selinuxfs for initial policy load. And it may break rc scripts and other scripts/programs that have become accustomed to /selinux. -- Stephen Smalley National Security Agency ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
