On Wed, 23 Jan 2008, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Make sure that you or Dan submits a policy patch to register these
> > classes and permissions in the policy when the kernel patch is queued
> > for merge.
>
> Do I just send the attached patch to
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Make sure that you or Dan submits a policy patch to register these
> classes and permissions in the policy when the kernel patch is queued
> for merge.
Do I just send the attached patch to <[EMAIL PROTECTED]>? Or do I need to
make a diff from a point
Stephen Smalley [EMAIL PROTECTED] wrote:
Make sure that you or Dan submits a policy patch to register these
classes and permissions in the policy when the kernel patch is queued
for merge.
Do I just send the attached patch to [EMAIL PROTECTED]? Or do I need to
make a diff from a point in the
--- David Howells <[EMAIL PROTECTED]> wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > The cache files are created by the cachefiles kernel module, not by the
> > userspace daemon, and the userspace daemon doesn't need to directly
> > read/write them at all
>
> That is correct.
>
> >
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> The cache files are created by the cachefiles kernel module, not by the
> userspace daemon, and the userspace daemon doesn't need to directly
> read/write them at all
That is correct.
> (but I think it does need to be able to unlink them?).
Indeed.
On Tue, 2008-01-15 at 10:10 -0800, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> wrote:
>
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > > (3) Check that the kernel may create files as a particular secid (this
> > > > could be specified indirectly by specifying
--- David Howells <[EMAIL PROTECTED]> wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > (3) Check that the kernel may create files as a particular secid (this
> > > could be specified indirectly by specifying an inode, which would
> > > hide the secid inside the LSM).
> >
On Tue, 2008-01-15 at 16:03 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > (3) Check that the kernel may create files as a particular secid (this
> > > could be specified indirectly by specifying an inode, which would
> > > hide the secid inside the
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > (3) Check that the kernel may create files as a particular secid (this
> > could be specified indirectly by specifying an inode, which would
> > hide the secid inside the LSM).
>
> I don't think this check is on the kernel per se but
On Mon, 2008-01-14 at 14:06 +, David Howells wrote:
> David Howells <[EMAIL PROTECTED]> wrote:
>
> > Okay... It looks like I want four security operations/hooks for cachefiles:
>
> FYI, I added the following vectors:
>
> # kernel services that need to override task security
>
On Mon, 2008-01-14 at 14:01 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > avc_has_perm(daemon_tsec->sid, nominated_sid,
> > >SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
> > >
> > > And I assume this doesn't care if one, the other or both
On Mon, 2008-01-14 at 14:01 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
And I assume this doesn't care if one, the other or both of the two SIDs
On Mon, 2008-01-14 at 14:06 +, David Howells wrote:
David Howells [EMAIL PROTECTED] wrote:
Okay... It looks like I want four security operations/hooks for cachefiles:
FYI, I added the following vectors:
# kernel services that need to override task security
class
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which would
hide the secid inside the LSM).
I don't think this check is on the kernel per se but rather the
On Tue, 2008-01-15 at 16:03 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which would
hide the secid inside the LSM).
I
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which would
hide the secid inside the LSM).
I don't think
On Tue, 2008-01-15 at 10:10 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
(3) Check that the kernel may create files as a particular secid (this
could be specified indirectly by specifying an inode, which
Stephen Smalley [EMAIL PROTECTED] wrote:
The cache files are created by the cachefiles kernel module, not by the
userspace daemon, and the userspace daemon doesn't need to directly
read/write them at all
That is correct.
(but I think it does need to be able to unlink them?).
Indeed.
The
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
The cache files are created by the cachefiles kernel module, not by the
userspace daemon, and the userspace daemon doesn't need to directly
read/write them at all
That is correct.
(but I think it
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> Yes, and I would recommend doing so to avoid permission races.
> You're going to have to deal with the case where step (2) fails
> even if you have step (1), so the "test and set" mindset seems
> prudent to me.
Looking at SELinux, that doesn't get rid
--- David Howells <[EMAIL PROTECTED]> wrote:
>
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > avc_has_perm(daemon_tsec->sid, nominated_sid,
> > >SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
> > >
> > > And I assume this doesn't care if one, the other or both of the
David Howells <[EMAIL PROTECTED]> wrote:
> Okay... It looks like I want four security operations/hooks for cachefiles:
FYI, I added the following vectors:
# kernel services that need to override task security
class kernel_service
{
use_as_override
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > avc_has_perm(daemon_tsec->sid, nominated_sid,
> > SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
> >
> > And I assume this doesn't care if one, the other or both of the two SIDs
> > mentioned are of SECCLASS_PROCESS rather than
Stephen Smalley [EMAIL PROTECTED] wrote:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
And I assume this doesn't care if one, the other or both of the two SIDs
mentioned are of SECCLASS_PROCESS rather than of
David Howells [EMAIL PROTECTED] wrote:
Okay... It looks like I want four security operations/hooks for cachefiles:
FYI, I added the following vectors:
# kernel services that need to override task security
class kernel_service
{
use_as_override
--- David Howells [EMAIL PROTECTED] wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
And I assume this doesn't care if one, the other or both of the two SIDs
mentioned
Casey Schaufler [EMAIL PROTECTED] wrote:
Yes, and I would recommend doing so to avoid permission races.
You're going to have to deal with the case where step (2) fails
even if you have step (1), so the test and set mindset seems
prudent to me.
Looking at SELinux, that doesn't get rid of the
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> If you have a "SELinux: policy loaded with handle_unknown=allow"
> message in your /var/log/messages, then new classes/perms that are not
> yet known to the policy will be allowed by default, so the operation
> will be permitted by the kernel.
I
Stephen Smalley [EMAIL PROTECTED] wrote:
If you have a SELinux: policy loaded with handle_unknown=allow
message in your /var/log/messages, then new classes/perms that are not
yet known to the policy will be allowed by default, so the operation
will be permitted by the kernel.
I don't. How
On Wed, 2008-01-09 at 18:56 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Right, the latter is reasonable.
> > Requires adding the class and permission definition to
> > policy/flask/security_classes and policy/flask/access_vectors and then
> > regenerating the
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Right, the latter is reasonable.
> Requires adding the class and permission definition to
> policy/flask/security_classes and policy/flask/access_vectors and then
> regenerating the kernel headers from those files, ala:
> svn co
On Wed, 2008-01-09 at 16:51 +, David Howells wrote:
> Okay. I can:
>
> (1) Have cachefilesd (the daemon) pass a security context string to the
> cachefiles kernel module, which can then convert it to a secID. It'll
> require a security_secctx_to_secid() function, but I'm fairly
David Howells <[EMAIL PROTECTED]> wrote:
> Now, I recall the addition of another security class being mentioned, which
> presumably would give something like:
>
> avc_has_perm(daemon_tsec->sid, nominated_sid,
>SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
H... I
Okay. I can:
(1) Have cachefilesd (the daemon) pass a security context string to the
cachefiles kernel module, which can then convert it to a secID. It'll
require a security_secctx_to_secid() function, but I'm fairly certain I
have a patch to add such kicking around somewhere.
Okay. I can:
(1) Have cachefilesd (the daemon) pass a security context string to the
cachefiles kernel module, which can then convert it to a secID. It'll
require a security_secctx_to_secid() function, but I'm fairly certain I
have a patch to add such kicking around somewhere.
David Howells [EMAIL PROTECTED] wrote:
Now, I recall the addition of another security class being mentioned, which
presumably would give something like:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
H... I can't
On Wed, 2008-01-09 at 16:51 +, David Howells wrote:
Okay. I can:
(1) Have cachefilesd (the daemon) pass a security context string to the
cachefiles kernel module, which can then convert it to a secID. It'll
require a security_secctx_to_secid() function, but I'm fairly
Stephen Smalley [EMAIL PROTECTED] wrote:
Right, the latter is reasonable.
Requires adding the class and permission definition to
policy/flask/security_classes and policy/flask/access_vectors and then
regenerating the kernel headers from those files, ala:
svn co
On Wed, 2008-01-09 at 18:56 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Right, the latter is reasonable.
Requires adding the class and permission definition to
policy/flask/security_classes and policy/flask/access_vectors and then
regenerating the kernel
Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > This is used, for example, by CacheFiles which has to transparently access
> > the cache on behalf of a process that thinks it is doing, say, NFS
> > accesses with a potentially inappropriate (with respect to accessing the
> > cache) set of security
On Tue, 2007-12-18 at 19:28 -0800, Crispin Cowan wrote:
> Stephen Smalley wrote:
> >> It is if I have to maintain a special pieces of code for each possible LSM.
> >> One piece for SELinux, one piece for AppArmour, one piece for Smack, one
> >> piece
> >> for Casey's security system. That sounds
On Tue, 2007-12-18 at 19:28 -0800, Crispin Cowan wrote:
Stephen Smalley wrote:
It is if I have to maintain a special pieces of code for each possible LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one
piece
for Casey's security system. That sounds like a pain.
Crispin Cowan [EMAIL PROTECTED] wrote:
This is used, for example, by CacheFiles which has to transparently access
the cache on behalf of a process that thinks it is doing, say, NFS
accesses with a potentially inappropriate (with respect to accessing the
cache) set of security data.
I'm
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Stephen Smalley wrote:
> >> It is if I have to maintain a special pieces of code for each possible
> LSM.
> >> One piece for SELinux, one piece for AppArmour, one piece for Smack, one
> piece
> >> for Casey's security system. That sounds like a
Stephen Smalley wrote:
>> It is if I have to maintain a special pieces of code for each possible LSM.
>> One piece for SELinux, one piece for AppArmour, one piece for Smack, one
>> piece
>> for Casey's security system. That sounds like a pain.
>>
> All your code has to do is invoke a
David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>>> That sounds too SELinux specific. How do I do it so that it works for any
>>> LSM?
>>>
>> You can't. There is no LSM for userspace; LSM specifically disavowed
>> any common userspace API, and that was one of our
David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
That sounds too SELinux specific. How do I do it so that it works for any
LSM?
You can't. There is no LSM for userspace; LSM specifically disavowed
any common userspace API, and that was one of our original
Stephen Smalley wrote:
It is if I have to maintain a special pieces of code for each possible LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one
piece
for Casey's security system. That sounds like a pain.
All your code has to do is invoke a function provided
--- Crispin Cowan [EMAIL PROTECTED] wrote:
Stephen Smalley wrote:
It is if I have to maintain a special pieces of code for each possible
LSM.
One piece for SELinux, one piece for AppArmour, one piece for Smack, one
piece
for Casey's security system. That sounds like a pain.
It's
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Do any of the interfaces allow a task to act on a cache other than one
> it has created?
No.
> How does the task identify the desired cache?
Each file descriptor opened creates one separate cache instance. Any commands
sent over that filedescriptor
On Thu, 2007-12-13 at 17:01 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > They would correspond with the operations provided by the /dev/cachefiles
> > interface, at the granularity you want to support distinctions to be made.
>
> Can this be made simpler by the
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> They would correspond with the operations provided by the /dev/cachefiles
> interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact that /dev/cachefiles has its own unique
label
On Thu, 2007-12-13 at 15:36 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > It is just a way of carving up the permission space, typically based on
> > object type, but it can essentially be arbitrary. The check in this
> > case seems specific to cachefiles since
Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> Yes, we could easily make a simple program that just invokes a
> libselinux function that in turn grabs the proper context from some
> context configuration file under /etc/selinux/$SELINUXTYPE/contexts/ and
> outputs it. Dan can help with that.
On Wed, 2007-12-12 at 22:55 +, David Howells wrote:
> 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
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> It is just a way of carving up the permission space, typically based on
> object type, but it can essentially be arbitrary. The check in this
> case seems specific to cachefiles since it is controlling an operation
> on the /dev/cachefiles interface
On Wed, 2007-12-12 at 22:49 +, David Howells wrote:
> 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
On Wed, 2007-12-12 at 22:49 +, David Howells wrote:
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
On Wed, 2007-12-12 at 22:55 +, David Howells wrote:
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
Stephen Smalley [EMAIL PROTECTED] wrote:
It is just a way of carving up the permission space, typically based on
object type, but it can essentially be arbitrary. The check in this
case seems specific to cachefiles since it is controlling an operation
on the /dev/cachefiles interface that
Stephen Smalley [EMAIL PROTECTED] wrote:
Yes, we could easily make a simple program that just invokes a
libselinux function that in turn grabs the proper context from some
context configuration file under /etc/selinux/$SELINUXTYPE/contexts/ and
outputs it. Dan can help with that.
That
On Thu, 2007-12-13 at 15:36 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
It is just a way of carving up the permission space, typically based on
object type, but it can essentially be arbitrary. The check in this
case seems specific to cachefiles since it is
Stephen Smalley [EMAIL PROTECTED] wrote:
They would correspond with the operations provided by the /dev/cachefiles
interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact that /dev/cachefiles has its own unique
label (cachefiles_dev_t).
On Thu, 2007-12-13 at 17:01 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
They would correspond with the operations provided by the /dev/cachefiles
interface, at the granularity you want to support distinctions to be made.
Can this be made simpler by the fact that
Stephen Smalley [EMAIL PROTECTED] wrote:
Do any of the interfaces allow a task to act on a cache other than one
it has created?
No.
How does the task identify the desired cache?
Each file descriptor opened creates one separate cache instance. Any commands
sent over that filedescriptor
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
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> It would seem to me that security_secctx_to_secid() ought to suffice if the
> application code was written correctly.
That's not quite sufficient as there still needs to be a verification step to
make sure the caller is allowed to do this.
> Be aware
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
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
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
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 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
> > > >
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
> > >
--- 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
--- David Howells <[EMAIL PROTECTED]> 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
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
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
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-kernel" in
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 "",
> > but that can be separate and LSM specific without
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:
> > > >
> > > >
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
>
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
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 "",
> but that can be separate and LSM specific without mucking up your basic
> infrastructure applications.
--- 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.
>
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 libselinux means it's a special case for a
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
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 know very much about using
SELinux userspace stuff libraries
On Tue, 2007-12-11 at 14:37 -0500, Stephen Smalley wrote:
> On Mon, 2007-12-10 at 23:36 +, David Howells wrote:
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > From a config file whose pathname would be provided by libselinux (ala
> > > the way in which dbusd imports contexts), or
On Tue, 2007-12-11 at 14:37 -0500, Stephen Smalley wrote:
On Mon, 2007-12-10 at 23:36 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
From a config file whose pathname would be provided by libselinux (ala
the way in which dbusd imports contexts), or directly as a
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 know very much about using
SELinux userspace stuff libraries or
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
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 libselinux means it's a special case for a specific LSM.
I
--- 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
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.
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
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
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
--- 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-kernel in
the body
--- 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
1 - 100 of 153 matches
Mail list logo
