--- 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
that to have been done by
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
--- 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 authorize the use 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
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 that
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
--- 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 think the best way to do this, then, has to be to
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 think the best way to do this, then, has to be to dlopen the appropriate LSM
library. That way I don't need to do
On Tue, 2007-12-11 at 20:42 +, 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
--- David Howells <[EMAIL PROTECTED]> wrote:
...
>
> How about I just stick the context in /etc/cachefilesd.conf as a textual
> configuration item and have the daemon pass that as a string to the
> cachefiles
> kernel module, which can then ask LSM if it's valid to set this context as an
>
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
> objections/concerns about
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > I am much more concerned with the interfaces used to pass the
> > information into the kernel. I would expect that to be LSM
> > independent, not a call into libselinux that resolves into a
> > selinuxfs operation, or it's netlink equivilant.
On Tue, 2007-12-11 at 11:26 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
> > > --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
>
On Mon, 2007-12-10 at 15:46 -0800, Casey Schaufler wrote:
> --- David Howells <[EMAIL PROTECTED]> 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
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 context
> > returned by a libselinux function.
>
> That
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
> > --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> > > > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> > > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > >
> > > > Otherwise, only other issue I have with this interface is it
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue
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 context
returned by a libselinux function.
That sounds too
On Mon, 2007-12-10 at 15:46 -0800, Casey Schaufler wrote:
--- David Howells [EMAIL PROTECTED] 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 context
On Tue, 2007-12-11 at 11:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 14:26 -0800, Casey Schaufler wrote:
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley
--- Stephen Smalley [EMAIL PROTECTED] wrote:
I am much more concerned with the interfaces used to pass the
information into the kernel. I would expect that to be LSM
independent, not a call into libselinux that resolves into a
selinuxfs operation, or it's netlink equivilant. It would
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
objections/concerns about it.
So,
--- David Howells [EMAIL PROTECTED] wrote:
...
How about I just stick the context in /etc/cachefilesd.conf as a textual
configuration item and have the daemon pass that as a string to the
cachefiles
kernel module, which can then ask LSM if it's valid to set this context as an
override,
On Tue, 2007-12-11 at 20:42 +, 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
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 think the best way to do this, then, has to be to dlopen the appropriate LSM
library. That way I don't need to do
--- 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 think the best way to do this, then, has to be to dlopen the
--- David Howells <[EMAIL PROTECTED]> wrote:
> Casey Schaufler <[EMAIL PROTECTED]> wrote:
>
> > That happens to me when interfaces are described in SELinux terms. I
> > still don't care much for multiple contexts, and I don't have a good
> > grasp of how you'll deal with Smack, or any LSM other
--- David Howells <[EMAIL PROTECTED]> 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 context
> > returned by a libselinux function.
>
> That sounds
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> That happens to me when interfaces are described in SELinux terms. I
> still don't care much for multiple contexts, and I don't have a good
> grasp of how you'll deal with Smack, or any LSM other than SELinux.
Me neither. I understand SELinux
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 context
> returned by a libselinux function.
That sounds too SELinux specific. How do I do it so that it works for any
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> > Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> > > Otherwise, only other issue I have with this interface is it won't
> > > generalize to dealing with nfsd, where we want to set the
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Otherwise, only other issue I have with this interface is it won't
> > generalize to dealing with nfsd, where we want to set the acting context
> > to a context we obtain from or determine
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Otherwise, only other issue I have with this interface is it won't
> generalize to dealing with nfsd, where we want to set the acting context
> to a context we obtain from or determine based upon the client.
Are you speaking of
On Mon, 2007-12-10 at 17:07 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > + tsec->create_sid = SECINITSID_UNLABELED;
> > > + tsec->keycreate_sid = SECINITSID_UNLABELED;
> > > + tsec->sockcreate_sid = SECINITSID_UNLABELED;
>
> Cleared means what? Setting to 0?
Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > + tsec->create_sid = SECINITSID_UNLABELED;
> > + tsec->keycreate_sid = SECINITSID_UNLABELED;
> > + tsec->sockcreate_sid = SECINITSID_UNLABELED;
Cleared means what? Setting to 0? Or is there some other constant I should
use for that?
David
On Wed, 2007-12-05 at 19:38 +, David Howells wrote:
> Allow kernel services to override LSM settings appropriate to the actions
> performed by a task by duplicating a security record, modifying it and then
> using task_struct::act_as to point to it when performing operations on behalf
> of a
On Wed, 2007-12-05 at 19:38 +, David Howells wrote:
Allow kernel services to override LSM settings appropriate to the actions
performed by a task by duplicating a security record, modifying it and then
using task_struct::act_as to point to it when performing operations on behalf
of a task.
Stephen Smalley [EMAIL PROTECTED] wrote:
+ tsec-create_sid = SECINITSID_UNLABELED;
+ tsec-keycreate_sid = SECINITSID_UNLABELED;
+ tsec-sockcreate_sid = SECINITSID_UNLABELED;
Cleared means what? Setting to 0? Or is there some other constant I should
use for that?
David
--
To
On Mon, 2007-12-10 at 17:07 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
+ tsec-create_sid = SECINITSID_UNLABELED;
+ tsec-keycreate_sid = SECINITSID_UNLABELED;
+ tsec-sockcreate_sid = SECINITSID_UNLABELED;
Cleared means what? Setting to 0? Or is there some
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize to dealing with nfsd, where we want to set the acting context
to a context we obtain from or determine based upon the client.
Are you speaking of security_kernel_act_as() and
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize to dealing with nfsd, where we want to set the acting context
to a context we obtain from or determine based upon
--- Stephen Smalley [EMAIL PROTECTED] wrote:
On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
Stephen Smalley [EMAIL PROTECTED] wrote:
Otherwise, only other issue I have with this interface is it won't
generalize to dealing with nfsd, where we want to set the acting context
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 context
returned by a libselinux function.
That sounds too SELinux specific. How do I do it so that it works for any
LSM?
Casey Schaufler [EMAIL PROTECTED] wrote:
That happens to me when interfaces are described in SELinux terms. I
still don't care much for multiple contexts, and I don't have a good
grasp of how you'll deal with Smack, or any LSM other than SELinux.
Me neither. I understand SELinux somewhat,
--- David Howells [EMAIL PROTECTED] 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 context
returned by a libselinux function.
That sounds too SELinux
--- David Howells [EMAIL PROTECTED] wrote:
Casey Schaufler [EMAIL PROTECTED] wrote:
That happens to me when interfaces are described in SELinux terms. I
still don't care much for multiple contexts, and I don't have a good
grasp of how you'll deal with Smack, or any LSM other than
Allow kernel services to override LSM settings appropriate to the actions
performed by a task by duplicating a security record, modifying it and then
using task_struct::act_as to point to it when performing operations on behalf
of a task.
This is used, for example, by CacheFiles which has to
Allow kernel services to override LSM settings appropriate to the actions
performed by a task by duplicating a security record, modifying it and then
using task_struct::act_as to point to it when performing operations on behalf
of a task.
This is used, for example, by CacheFiles which has to
101 - 153 of 153 matches
Mail list logo
