Re: [systemd-devel] [PATCH] selinux: Only attempt to load policy exactly once, in the real root

2014-02-20 Thread Eric Paris 
Not really.  If it doesn't exist on the final root fs and I put
enforcing=1 on the command line, I expect the box to
panic/fail/die/whatever

On Thu, Feb 20, 2014 at 1:36 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 20.02.14 18:17, Colin Walters (walt...@verbum.org) wrote:

 Hmm, maybe a simple check access(/etc/selinux/, F_OK) would be enough?
 There's no point in trying to initialized SELinux if that dir does not
 exist, right? Then we could simply bypass the whole thing...

 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?


 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel



 Lennart

 --
 Lennart Poettering, Red Hat
 ___
 Selinux mailing list
 seli...@tycho.nsa.gov
 To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
 To get help, send an email containing help to selinux-requ...@tycho.nsa.gov.
___
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

2014-02-20 Thread Eric Paris 
I like it, if it's reasonable/possible

On Thu, Feb 20, 2014 at 2:26 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 20.02.14 13:50, Eric Paris (epa...@parisplace.org) wrote:

 Not really.  If it doesn't exist on the final root fs and I put
 enforcing=1 on the command line, I expect the box to
 panic/fail/die/whatever

 OK, then maybe check !in_initrd() || access(/etc/selinux/, F_OK) = 0?

 Lennart

 --
 Lennart Poettering, Red Hat
___
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

2014-02-20 Thread Eric Paris 
I think the idea was

if we are not in the initrd - try to load policy
if we are in the initrd and we find selinux_path() - try to load policy

Thus embeded/thin who put everything inside the initrd will work (and
the kernel enforce=1 will mean what is should)
And where we don't put anything inside the initrd will still be
correct since we'll try to load no matter what in the real root

On Thu, Feb 20, 2014 at 3:52 PM, Colin Walters walt...@verbum.org wrote:
 On Thu, Feb 20, 2014 at 2:45 PM, Daniel J Walsh dwa...@redhat.com wrote:

 You mean !in_initrd() || access(selinux_path(), F_OK) = 0?


 I don't think so - that would mean we would silently continue if
 enforcing=1, but we happen to not find a policy on disk.  Right?

 I think my patch is better than this - systemd will attempt to load policy
 from *only* the real root (not the initramfs), using the exact same logic as
 is in libselinux currently.

 For example, it would allow explicitly specifying enforcing=1 on the kernel
 command line, and that would continue to cause an explicit failure if policy
 is not found.



 ___
 Selinux mailing list
 seli...@tycho.nsa.gov
 To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
 To get help, send an email containing help to
 selinux-requ...@tycho.nsa.gov.

___
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

2011-05-11 Thread Eric Paris 
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?

-Eric
___
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

2011-05-11 Thread Eric Paris 
On Wed, May 11, 2011 at 11:13 AM, Stephen Smalley s...@tycho.nsa.gov wrote:
 On Wed, 2011-05-11 at 10:58 -0400, Eric Paris wrote:
 On Wed, May 11, 2011 at 10:54 AM, John Johansen

  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.

The reason we would move to /sys/security/ instead of /sys/fs/ is
because other LSMs are already there and it would look consistent.
Obviously where selinuxfs gets mounted it determined by userspace and
is going to require a tools change.  The tools could mount securityfs
if it wasn't mounted.  Obviously it would mean SELinux would have to
select securityfs even though we didn't use it

I'm up for either location, but I'm leaning towards /sys/security/
instead of /sys/fs if we know that's where other LSMs are going to
live...

-Eric
___
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

2011-05-11 Thread Eric Paris 
On Tue, May 10, 2011 at 6:34 PM, Greg KH g...@kroah.com 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

security/selinux/selinuxfs.c: In function ‘init_sel_fs’:
security/selinux/selinuxfs.c:1909: error: ‘selinux_kobj’ undeclared
(first use in this function)
security/selinux/selinuxfs.c:1909: error: (Each undeclared identifier
is reported only once
security/selinux/selinuxfs.c:1909: error: for each function it appears in.)
security/selinux/selinuxfs.c: In function ‘exit_sel_fs’:
security/selinux/selinuxfs.c:1934: error: implicit declaration of
function ‘kobjext_put’
security/selinux/selinuxfs.c:1934: error: ‘selinux_kobj’ undeclared
(first use in this function)
make[2]: *** [security/selinux/selinuxfs.o] Error 1
make[2]: *** Waiting for unfinished jobs











 ---

 Resend, due to lack of response.

 Note, patch is untested, I don't have any selinux-based machines here,
 sorry.


 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
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
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

2011-05-11 Thread Eric Paris 
On Wed, May 11, 2011 at 12:35 PM, Eric Paris epa...@parisplace.org wrote:
 On Tue, May 10, 2011 at 6:34 PM, Greg KH g...@kroah.com 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.

I just committed the attached patch to my -next tree.

-Eric
commit 0599ea55fd0a0fc3b647dbf1ade09f9c0ddd8c05
Author: Greg Kroah-Hartman gre...@suse.de
Date:   Tue May 10 15:34:16 2011 -0700

SELINUX: add /sys/fs/selinux mount point to put selinuxfs

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
[include kobject.h - Eric Paris]
[use selinuxfs_obj throughout - Eric Paris]
Signed-off-by: Eric Paris epa...@redhat.com

diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index ea39cb7..ea756a6 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -28,6 +28,7 @@
 #include linux/percpu.h
 #include linux/audit.h
 #include linux/uaccess.h
+#include linux/kobject.h
 
 /* selinuxfs pseudo filesystem for exporting the security policy API.
Based on the proc code and the fs/nfsd/nfsctl.c code. */
@@ -1897,6 +1898,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 +1906,16 @@ static int __init init_sel_fs(void)
 
 	if (!selinux_enabled)
 		return 0;
+
+	selinuxfs_kobj = kobject_create_and_add(selinux, fs_kobj);
+	if (!selinuxfs_kobj)
+		return -ENOMEM;
+
 	err = register_filesystem(sel_fs_type);
-	if (err)
+	if (err) {
+		kobject_put(selinuxfs_kobj);
 		return err;
+	}
 
 	selinuxfs_mount = kern_mount(sel_fs_type);
 	if (IS_ERR(selinuxfs_mount)) {
@@ -1923,6 +1932,7 @@ __initcall(init_sel_fs);
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 void exit_sel_fs(void)
 {
+	kobject_put(selinuxfs_kobj);
 	unregister_filesystem(sel_fs_type);
 }
 #endif
___
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

2011-05-11 Thread Eric Paris 
On Wed, May 11, 2011 at 3:56 PM, Greg KH g...@kroah.com wrote:
 On Wed, May 11, 2011 at 10:14:40AM -0700, Casey Schaufler wrote:
 I would prefer /sys/security for all LSMs, but if SELinux goes with /sys/fs
 Smack will likely follow on the theory that mirroring the current dominant
 LSM is more likely to please the masses than doing what the greatest number
 of LSMs are doing.

 Is smack going to create its own filesystem like selinux has, or is it
 going to use securityfs?  If securityfs, then stick with what you have.
 If you are going to create a new one, I'd be glad to work with you to
 add anything you might need to securityfs first, but if that doesn't
 work out, then yes, you could use /sys/fs/ for your new one.

Pretty sure we already have a securty/smack/smackfs.c .

-Eric
___
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

2011-05-02 Thread Eric Paris 
On Mon, 2011-05-02 at 15:02 -0700, Greg KH wrote:
 On Mon, May 02, 2011 at 09:24:40AM -0400, Stephen Smalley wrote:
  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?
 
 Correct.
 
  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?
 
 Yes it is.
 
 Care to forward this on to James for the next kernel merge window?

I'll pick it up in the selinux tree when my machine finished
reinstalling.

-Eric

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

2011-04-20 Thread Eric Paris 
On Wed, 2011-04-20 at 12:16 +0200, Aurelien Jarno wrote:
 On Wed, Apr 20, 2011 at 03:22:08AM +0200, Lennart Poettering wrote:
  On Wed, 20.04.11 09:15, fykc...@gmail.com (fykc...@gmail.com) wrote:
  
   
   2011/4/20 Lennart Poettering lenn...@poettering.net
   
On Thu, 14.04.11 17:34, fykc...@gmail.com (fykc...@gmail.com) wrote:
   
 diff --git a/src/missing.h b/src/missing.h
 index 35e209f..b367831 100644
 --- a/src/missing.h
 +++ b/src/missing.h
 @@ -125,7 +125,12 @@ static inline int fanotify_init(unsigned int 
 flags, unsigned int event_f_flags)

  static inline int fanotify_mark(int fanotify_fd, unsigned int flags, 
 uint64_t mask,
  int dfd, const char *pathname) {
 -return syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, 
 dfd, pathname);
 +if (sizeof(void *) == 4)
 +return syscall(__NR_fanotify_mark, fanotify_fd, 
 flags,
 +   *((uint32_t *) mask), *((uint32_t *) 
 mask + 1),
 +   dfd, pathname);
 +else /* 64bit */
 +return syscall(__NR_fanotify_mark, fanotify_fd, 
 flags, mask, dfd, pathname);
  }

  #ifndef BTRFS_IOCTL_MAGIC
   
Hmm, wouldn't this break x86-32?
   It works fine on my asus laptop with a 32bit CPU Pentium-M.
   
   We pass two 32bit arguments instead of one 64bit argument. syscall()
   doesn't know the prototype, I guess it will only fetch 9 native-width
   arguments(1 syscall number + 8 parameters) from the stack. Aurelien,
   am I right?
  
  Hmm, I am not sure I understand this? How is it possible that both ways
  work on x86? There must be quite a difference between passing 6 or 7
  arguments to syscall.
 
 syscall(64_bit_arg) actually pass the 64-bit argument in two different
 registers (or on two different 32-bit stack entries). Then the GNU libc
 copies the registers while converting from the userspace ABI to the
 kernel ABI (usually passing more values into registers).
 
 On a lot of 32-bit cpus which needs alignment, a 64-bit arguments have 
 to be stack aligned, or register aligned. That's why due to the userspace
 ABI, one register or one stack entry has to be empty. This later break
 when this empty register arrives at the kernel level.
 
  Or are you suggesting that the current invocation is broken even on x86,
  just doesn't become visible since only the lower 32 bit of mask are
  used?
  
 
 No, on x86 it just work by chance, as x86 is very flexible with
 alignement.

When I implemented the kernel interface I remember someone brought up
64-bit alignment and it was suggest I go with the ordering I have.  I
understood that fanotify_fd would be the first 32 bits, flags be the
second and then mask should be 64-bit aligned as the 3rd/4th?

I am pretty arch stupid, and I have no idea at all if it is related, but
I'm looking at kernel commit 5e844b31c2ace282ab8bea630b63e0212d9532d4
which wires up the fanotify syscalls for mips.  I see that it used a u64
for a3 and a4 when these are only going to be 32 values.  Does that
matter?  I also see that some prototype such as sys32_readahead()
explicitly added a pad into the 32 helper.  Should we be doing that?  I
also notice that the naming of arguments seems wrong (although it
shouldn't matter)

SYSCALL_DEFINE6(32_fanotify_mark, int, fanotify_fd, unsigned int, flags,
u64, a3, u64, a4, int, dfd, const char  __user *, pathname)

I would have thought equivalently:
  fanotify_fd == a0
  flags == a1
  'a3' == a2
  'a4' == a3
  dfd == a4

etc.

Anyway, no idea if it is related, but I thought I designed the
systemcall with this padding in mind.

-Eric

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel