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
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 [EMAIL
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
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
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 don't. How
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
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
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.
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
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
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
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
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
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
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
--- 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
--- 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,
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 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
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?
--- 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
56 matches
Mail list logo
