linux-kernel - Re: [PATCH] Smack: SMACK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADjiTvBkwusfjdE=PQ5B=MPMxr1bewR6v9qoqq6yMNWjp-BeLQ@mail.gmail.com>
Date:	Fri, 26 Aug 2011 19:05:27 +0300
From:	"Sakkinen, Jarkko" <jarkko.sakkinen@...el.com>
To:	Eric Paris <eparis@...isplace.org>
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 3:50 PM, Eric Paris <eparis@...isplace.org> wrote:
> 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

Thank you for this information. One thing that concerns
me in this approach is the scenario where things serialize
to the following sequence:

- Process A does open()
- Process B does open()
- Process A does write()
- Process B does write()
- Process A does read()
- ... (sequence continues)

What's the end result?

> 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)

I'm aware of the fact that IOCTLs should be avoided
but on the other hand in this use case I see it as the
cleanest possible API that enables clean and simple
user space support for access control and has least
risk for any side-effects.

>
> Anyway, just food for thought....
>
> -Eric
>

/Jarkko
--
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/