[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACLa4pvbaWM8jRJvBW2NvN2OLK8x4wP44pfdUQ9He1fZwWYcfA@mail.gmail.com>
Date: Fri, 26 Aug 2011 08:50:17 -0400
From: Eric Paris <eparis@...isplace.org>
To: Jarkko Sakkinen <jarkko.sakkinen@...el.com>
Cc: Casey Schaufler <casey@...aufler-ca.com>,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] Smack: SMACK_IOCLOADACCESS
On Fri, Aug 26, 2011 at 1:52 AM, Jarkko Sakkinen
<jarkko.sakkinen@...el.com> wrote:
> IOCTL call for /smack/load that takes access rule in
> the same format as they are written into /smack/load.
> Sets errno to zero if access is allowed and to EACCES
> if not.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...el.com>
[SELinux maintainer here, but Casey knew to already take what I say
with a grain of salt]
I'm not telling you to do anything differently, just telling you what
SELinux does, and why we do it. SELinux has a file in selinuxfs
called 'access.' The file can be opened and one can write a rule into
the file. One then calls read and gets back a structure which
contains all of the permissions information allowed for the
source/target/class. In SELinux we calculate all of the permissions
for the tuple at once so providing all of the information at once can
make a lot of sense. libselinux provides libraries that will cache
these decisions in the userspace program and quickly answer the same
(or similar) questions later.
http://userspace.selinuxproject.org/trac/browser/libselinux/src/compute_av.c
Shows the userspace side of out "access" interface. Your interface is
good in that it only takes 1 syscall and ours takes 2. Your interface
is bad in that it is ioctl and we are told since birth that we must
hate them no matter what (not that read/write is really any
different). It isn't the same method the only other LSM I know about
uses. It can only every return one value (ok, I know ioctl can be
made to do anything at all)
Anyway, just food for thought....
-Eric
--
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/
Powered by blists - more mailing lists