On Wed, 2007-12-12 at 14:53 +, David Howells wrote:
Karl MacMillan [EMAIL PROTECTED] wrote:
That's what I remember as well - I suggested the transition idea and
then, after discussion, agreed that it wasn't the best approach.
Sigh.
Can you tell me then how to do it now? I don't
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
All your code has to do is invoke a function provided by libselinux.
Calling
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I defined CAP_NS_UNSHARE as bit 32 as an experiment, and had to do some
finagling/combination of both of your trees to do so... Though that
aside I'm pleased to say it all
Casey Schaufler [EMAIL PROTECTED] wrote:
You may need to have an application, say cachefileselinuxcontext, that will
read the current policy and spit out an appropriate value of whatever,
but that can be separate and LSM specific without mucking up your basic
infrastructure applications.
On Wed, 2007-12-12 at 08:51 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Tue, 2007-12-11 at 15:04 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
All your code has to do is
Casey Schaufler [EMAIL PROTECTED] wrote:
What sort of authorization are you thinking of? I would expect
that to have been done by cachefileselinuxcontext (or
cachefilesspiffylsmcontext) up in userspace. If you're going to
rely on userspace applications for policy enforcement they need
to be
Stephen Smalley [EMAIL PROTECTED] wrote:
That sounds workable, although I think he will want a more specific hook
than security_secctx_to_secid(), or possibly a second hook call, that
would not only validate the context but authorize the use of it by the
cachefilesd process. And then the
--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
You may need to have an application, say cachefileselinuxcontext, that will
read the current policy and spit out an appropriate value of whatever,
but that can be separate and LSM specific without
Casey Schaufler [EMAIL PROTECTED] wrote:
Put the result into /etc/cachefiles.conf.
Ewww. Runtime mangling of the configuration. I suppose it doesn't have to be
in that file with the rest of the config.
David
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
What sort of authorization are you thinking of? I would expect
that to have been done by cachefileselinuxcontext (or
cachefilesspiffylsmcontext) up in userspace. If you're going to
rely on userspace
On Wed, 2007-12-12 at 18:29 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
That sounds workable, although I think he will want a more specific hook
than security_secctx_to_secid(), or possibly a second hook call, that
would not only validate the context but authorize
On Wed, 2007-12-12 at 11:44 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
What sort of authorization are you thinking of? I would expect
that to have been done by cachefileselinuxcontext (or
On Wed, 2007-12-12 at 11:20 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
You may need to have an application, say cachefileselinuxcontext, that
will
read the current policy and spit out an appropriate value of
Casey Schaufler [EMAIL PROTECTED] wrote:
Yes, but we're talking about writing the configuration information
to the kernel, not actually making any access checks with it. I
think. What I think we're talking about (and please correct me David
if I've stepped into the wrong theatre) is getting
Casey Schaufler [EMAIL PROTECTED] wrote:
This fd selects the
particular cache context that a particular instance of a running daemon is
using.
Yes, but forgive me being slow, I don't see the problem.
I mean that it's not particularly sensible to have an auxiliary interface (say
a
Stephen Smalley [EMAIL PROTECTED] wrote:
More likely, run it at build time in your .spec file to generate
cachefiles.conf,
I don't think sticking it in cachefiles.conf is a good idea necessarily.
That has to be an administrator modifiable file. Is there a program I could
make cachefiles run
Stephen Smalley [EMAIL PROTECTED] wrote:
Have you example code for the security hook you mention? I'm not sure I
understand why security_secctx_to_secid() is not sufficient.
security_secctx_to_secid() would just validate and map a context string to a
secid.
Validate as in check it's a
Sigh,
sorry, ignore me. Wrong kernel branch!
icouldasworn...
-serge
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge
[EMAIL PROTECTED] wrote:
Quoting Andrew Morgan ([EMAIL PROTECTED]):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I defined CAP_NS_UNSHARE as bit 32 as an experiment, and had to do some
finagling/combination of both of your trees to do so... Though that
aside I'm
19 matches
Mail list logo
