Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 PROTECTED]>?
That should be enough (and that list is on the cc).
>Or do I need to
> make a diff from a point in the tree nearer the root? Is there anything else
> I need to alter whilst I'm at it?
>
> David
> ---
> Index: policy/flask/security_classes
> ===
> --- policy/flask/security_classes (revision 2573)
> +++ policy/flask/security_classes (working copy)
> @@ -109,4 +109,7 @@
> # network peer labels
> class peer
>
> +# kernel services that need to override task security
> +class kernel_service
> +
> # FLASK
> Index: policy/flask/access_vectors
> ===
> --- policy/flask/access_vectors (revision 2573)
> +++ policy/flask/access_vectors (working copy)
> @@ -736,3 +736,10 @@
> {
> recv
> }
> +
> +# kernel services that need to override task security
> +class kernel_service
> +{
> + use_as_override
> + create_files_as
> +}
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-security-module" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
James Morris
<[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 tree nearer the root? Is there anything else
I need to alter whilst I'm at it?
David
---
Index: policy/flask/security_classes
===
--- policy/flask/security_classes (revision 2573)
+++ policy/flask/security_classes (working copy)
@@ -109,4 +109,7 @@
# network peer labels
class peer
+# kernel services that need to override task security
+class kernel_service
+
# FLASK
Index: policy/flask/access_vectors
===
--- policy/flask/access_vectors (revision 2573)
+++ policy/flask/access_vectors (working copy)
@@ -736,3 +736,10 @@
{
recv
}
+
+# kernel services that need to override task security
+class kernel_service
+{
+ use_as_override
+ create_files_as
+}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 tree nearer the root? Is there anything else
I need to alter whilst I'm at it?
David
---
Index: policy/flask/security_classes
===
--- policy/flask/security_classes (revision 2573)
+++ policy/flask/security_classes (working copy)
@@ -109,4 +109,7 @@
# network peer labels
class peer
+# kernel services that need to override task security
+class kernel_service
+
# FLASK
Index: policy/flask/access_vectors
===
--- policy/flask/access_vectors (revision 2573)
+++ policy/flask/access_vectors (working copy)
@@ -736,3 +736,10 @@
{
recv
}
+
+# kernel services that need to override task security
+class kernel_service
+{
+ use_as_override
+ create_files_as
+}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 does need to be able to unlink them?). > > Indeed. > > > The userspace daemon merely identifies the directory where the cache should > > live as part of configuring the cache when enabling it. > > That is the way it currently works, yes. > > > Hence, it is fine to use a fixed label for the cache files (systemhigh > > in a MLS world), and to let the directory's label serve as the basis for > > it. > > That is what I currently do. SELinux rules are provided to grant the > appropriate file accesses to the override label used by the kernel module, so > that it can't go and stamp on files with the wrong label. > > > Only the cachefiles kernel module directly reads and writes the files. > > Correct. Well, my bad, and thank you for clearing up my misunderstanding. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 userspace daemon merely identifies the directory where the cache should > live as part of configuring the cache when enabling it. That is the way it currently works, yes. > Hence, it is fine to use a fixed label for the cache files (systemhigh > in a MLS world), and to let the directory's label serve as the basis for > it. That is what I currently do. SELinux rules are provided to grant the appropriate file accesses to the override label used by the kernel module, so that it can't go and stamp on files with the wrong label. > Only the cachefiles kernel module directly reads and writes the files. Correct. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 would > > > > hide the secid inside the LSM). > > > > > > I don't think this check is on the kernel per se but rather the ability > > > of the daemon to nominate a secid for use on files created later by the > > > kernel module. > > > > Hmmm... At the moment the cachefiles module works out for itself what the > > file label should be by looking at the root directory it was given and > > assuming the label on that is what it's going to be using. Are you > > suggesting > > this should be specified directly instead by the daemon? > > Oh my. While there will be cases where the label of the file > will match the label of the containing directory, and in fact > for most label based LSMs that will usually be the case, you > certainly can't count on it. The only place that you can find > the correct label for a file with any confidence in from the > xattr (assuming the LSM uses xattrs) on the file itself. I can > imaging an LSM for which it would make sense to derive the > label from the root directory, but I know Smack isn't one of > them, and I don't think that SELinux is either, although I > would defer a definitive answer on that to Stephen. 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 (but I think it does need to be able to unlink them?). The userspace daemon merely identifies the directory where the cache should live as part of configuring the cache when enabling it. Hence, it is fine to use a fixed label for the cache files (systemhigh in a MLS world), and to let the directory's label serve as the basis for it. Only the cachefiles kernel module directly reads and writes the files. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 this check is on the kernel per se but rather the ability > > of the daemon to nominate a secid for use on files created later by the > > kernel module. > > Hmmm... At the moment the cachefiles module works out for itself what the > file label should be by looking at the root directory it was given and > assuming the label on that is what it's going to be using. Are you > suggesting > this should be specified directly instead by the daemon? Oh my. While there will be cases where the label of the file will match the label of the containing directory, and in fact for most label based LSMs that will usually be the case, you certainly can't count on it. The only place that you can find the correct label for a file with any confidence in from the xattr (assuming the LSM uses xattrs) on the file itself. I can imaging an LSM for which it would make sense to derive the label from the root directory, but I know Smack isn't one of them, and I don't think that SELinux is either, although I would defer a definitive answer on that to Stephen. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 don't think this check is on the kernel per se but rather the ability > > of the daemon to nominate a secid for use on files created later by the > > kernel module. > > Hmmm... At the moment the cachefiles module works out for itself what the > file label should be by looking at the root directory it was given and > assuming the label on that is what it's going to be using. Are you suggesting > this should be specified directly instead by the daemon? No, just that however the secid is determined (whether indirectly via specification of a directory or directly via specification of a secid), the ability of the daemon to control what secid gets used ought to be controlled. Or, alternatively, the ability of the daemon to enable caching in a given directory ought to be controlled. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 ability > of the daemon to nominate a secid for use on files created later by the > kernel module. Hmmm... At the moment the cachefiles module works out for itself what the file label should be by looking at the root directory it was given and assuming the label on that is what it's going to be using. Are you suggesting this should be specified directly instead by the daemon? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 kernel_service
> {
> use_as_override
> create_files_as
> }
>
> The first allows:
>
> avc_has_perm(daemon_tsec->sid, nominated_sid,
>SECCLASS_KERNEL_SERVICE,
>KERNEL_SERVICE__USE_AS_OVERRIDE,
>NULL);
>
> And the second something like:
>
> avc_has_perm(tsec->sid, inode->sid,
>SECCLASS_KERNEL_SERVICE,
>KERNEL_SERVICE__CREATE_FILES_AS,
>NULL);
>
> Rather than specifically dedicating them to the cache, I made them general.
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.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 > > > mentioned are of SECCLASS_PROCESS rather than of SECCLASS_CACHE. > > > > Right, the latter is reasonable. > > Okay... It looks like I want four security operations/hooks for cachefiles: > > (1) Check that a daemon can nominate a secid for use by the kernel to > override > the process subjective secid. > > (2) Set the secid mentioned in (1). > > (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 ability of the daemon to nominate a secid for use on files created later by the kernel module. > (4) Set the fscreate secid mentioned in (3). > > Now, it's possible to condense (1) and (2) into a single op, and condense (3) > and (4) into a single op. That, however, might make the ops unusable by nfsd, > which may well want to bypass the checks or do them elsewhere. > > Any thoughts? I think it is fine to combine them. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 mentioned are of SECCLASS_PROCESS rather than of SECCLASS_CACHE. Right, the latter is reasonable. Okay... It looks like I want four security operations/hooks for cachefiles: (1) Check that a daemon can nominate a secid for use by the kernel to override the process subjective secid. (2) Set the secid mentioned in (1). (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 ability of the daemon to nominate a secid for use on files created later by the kernel module. (4) Set the fscreate secid mentioned in (3). Now, it's possible to condense (1) and (2) into a single op, and condense (3) and (4) into a single op. That, however, might make the ops unusable by nfsd, which may well want to bypass the checks or do them elsewhere. Any thoughts? I think it is fine to combine them. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 kernel_service
{
use_as_override
create_files_as
}
The first allows:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__USE_AS_OVERRIDE,
NULL);
And the second something like:
avc_has_perm(tsec-sid, inode-sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__CREATE_FILES_AS,
NULL);
Rather than specifically dedicating them to the cache, I made them general.
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.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 ability of the daemon to nominate a secid for use on files created later by the kernel module. Hmmm... At the moment the cachefiles module works out for itself what the file label should be by looking at the root directory it was given and assuming the label on that is what it's going to be using. Are you suggesting this should be specified directly instead by the daemon? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 don't think this check is on the kernel per se but rather the ability of the daemon to nominate a secid for use on files created later by the kernel module. Hmmm... At the moment the cachefiles module works out for itself what the file label should be by looking at the root directory it was given and assuming the label on that is what it's going to be using. Are you suggesting this should be specified directly instead by the daemon? No, just that however the secid is determined (whether indirectly via specification of a directory or directly via specification of a secid), the ability of the daemon to control what secid gets used ought to be controlled. Or, alternatively, the ability of the daemon to enable caching in a given directory ought to be controlled. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 this check is on the kernel per se but rather the ability of the daemon to nominate a secid for use on files created later by the kernel module. Hmmm... At the moment the cachefiles module works out for itself what the file label should be by looking at the root directory it was given and assuming the label on that is what it's going to be using. Are you suggesting this should be specified directly instead by the daemon? Oh my. While there will be cases where the label of the file will match the label of the containing directory, and in fact for most label based LSMs that will usually be the case, you certainly can't count on it. The only place that you can find the correct label for a file with any confidence in from the xattr (assuming the LSM uses xattrs) on the file itself. I can imaging an LSM for which it would make sense to derive the label from the root directory, but I know Smack isn't one of them, and I don't think that SELinux is either, although I would defer a definitive answer on that to Stephen. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 would hide the secid inside the LSM). I don't think this check is on the kernel per se but rather the ability of the daemon to nominate a secid for use on files created later by the kernel module. Hmmm... At the moment the cachefiles module works out for itself what the file label should be by looking at the root directory it was given and assuming the label on that is what it's going to be using. Are you suggesting this should be specified directly instead by the daemon? Oh my. While there will be cases where the label of the file will match the label of the containing directory, and in fact for most label based LSMs that will usually be the case, you certainly can't count on it. The only place that you can find the correct label for a file with any confidence in from the xattr (assuming the LSM uses xattrs) on the file itself. I can imaging an LSM for which it would make sense to derive the label from the root directory, but I know Smack isn't one of them, and I don't think that SELinux is either, although I would defer a definitive answer on that to Stephen. 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 (but I think it does need to be able to unlink them?). The userspace daemon merely identifies the directory where the cache should live as part of configuring the cache when enabling it. Hence, it is fine to use a fixed label for the cache files (systemhigh in a MLS world), and to let the directory's label serve as the basis for it. Only the cachefiles kernel module directly reads and writes the files. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 userspace daemon merely identifies the directory where the cache should live as part of configuring the cache when enabling it. That is the way it currently works, yes. Hence, it is fine to use a fixed label for the cache files (systemhigh in a MLS world), and to let the directory's label serve as the basis for it. That is what I currently do. SELinux rules are provided to grant the appropriate file accesses to the override label used by the kernel module, so that it can't go and stamp on files with the wrong label. Only the cachefiles kernel module directly reads and writes the files. Correct. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 does need to be able to unlink them?). Indeed. The userspace daemon merely identifies the directory where the cache should live as part of configuring the cache when enabling it. That is the way it currently works, yes. Hence, it is fine to use a fixed label for the cache files (systemhigh in a MLS world), and to let the directory's label serve as the basis for it. That is what I currently do. SELinux rules are provided to grant the appropriate file accesses to the override label used by the kernel module, so that it can't go and stamp on files with the wrong label. Only the cachefiles kernel module directly reads and writes the files. Correct. Well, my bad, and thank you for clearing up my misunderstanding. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 permission race because there's no locking. This may be different for other models. I was thinking of having steps (2) and (4) not do any checking, but rather assume that the caller has done the checks before calling the set routines, possibly by calling the hooks mentioned in (1) and (3). My main problem is that I don't know how NFSd wants to do things. I suppose there *ought* to be rules that say what NFSd is allowed to do. > > and condense (3) and (4) into a single op. That, however, might make > > the ops unusable by nfsd, > > which may well want to bypass the checks or do them elsewhere. > > Again, I don't think you're doing yourself any favors with a separate > test operation. It doesn't matter to cachefiles, but it might matter to other users:-/ > On (4) are you suggesting a third attribute value? There's the secid > of the task originally, the secid you're going to use to do the access > checks, and the secid you're going to set the file to on creation. That's correct. Let me summarise: (1) The daemon has an active process security ID (say A). When the daemon nominates an override process security ID (say B) to be used by the kernel, the cachefiles module asks the LSM to check that A is allowed to nominate B for this purpose. (2) The cachefiles module is given a path under which its cache exists. The directory at the base of this path has its own security ID (say C). cachefiles wants to create new files in the cache with the same security ID as that directory (ie. C). However, when cachefiles is creating files in the cache, the security of whatever process is doing the access will be overridden with B, so cachefiles asks the LSM to check that B is allowed create files as C. Note that this is an instantaneous check in the cache startup stage. This allows caching to be aborted early if the security policy does not permit B to create Cs. Technically this check is superfluous as it's re-checked each time a vfs_mkdir() or vfs_create() are called. > > Any thoughts? > > Let me see if I understand your current scheme. > > You want a (object) secid that is used to access the task. That depends on what you mean. cachefilesd (the daemon) will be run with a security label because there's a security model in place. I don't actually need to access the daemon, but the daemon does need to do things for which it requires permission grants. > You want a (subject) secid that the task uses to accesses objects. Correct. This is used as an override by any task that accesses the cache indirectly through the cachefiles module. The cachefilesd daemon has its own secid with which it accesses the cache directly. The sets of permissions that must be granted by the module's override subjective secid and by the daemon's subjective secid aren't identical. > You want a (newobject) secid that an object gets on creation. File and directory objects, yes. The cache is stored on disk as a collection of files and directories, each of which needs labelling. > And you want them all to be distinct and settable. Well, they don't technically have to be different. The daemon and the module can be given the same secid, for instance. However, that secid then grants the daemon permission to anything the module can, and vice versa. The third secid is a file label rather than a process label, and so may or may not have to be different anyway, depending on the model. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 are of SECCLASS_PROCESS rather than of SECCLASS_CACHE. > > > > Right, the latter is reasonable. > > Okay... It looks like I want four security operations/hooks for cachefiles: > > (1) Check that a daemon can nominate a secid for use by the kernel to > override > the process subjective secid. > > (2) Set the secid mentioned in (1). > > (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). > > (4) Set the fscreate secid mentioned in (3). > > Now, it's possible to condense (1) and (2) into a single op, 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. > and condense (3) and (4) into a single op. That, however, might make > the ops unusable by nfsd, > which may well want to bypass the checks or do them elsewhere. Again, I don't think you're doing yourself any favors with a separate test operation. On (4) are you suggesting a third attribute value? There's the secid of the task originally, the secid you're going to use to do the access checks, and the secid you're going to set the file to on creation. > Any thoughts? Let me see if I understand your current scheme. You want a (object) secid that is used to access the task. You want a (subject) secid that the task uses to accesses objects. You want a (newobject) secid that an object gets on creation. And you want them all to be distinct and settable. Did I get that right? Thank you. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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
create_files_as
}
The first allows:
avc_has_perm(daemon_tsec->sid, nominated_sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__USE_AS_OVERRIDE,
NULL);
And the second something like:
avc_has_perm(tsec->sid, inode->sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__CREATE_FILES_AS,
NULL);
Rather than specifically dedicating them to the cache, I made them general.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 SECCLASS_CACHE. > > Right, the latter is reasonable. Okay... It looks like I want four security operations/hooks for cachefiles: (1) Check that a daemon can nominate a secid for use by the kernel to override the process subjective secid. (2) Set the secid mentioned in (1). (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). (4) Set the fscreate secid mentioned in (3). Now, it's possible to condense (1) and (2) into a single op, and condense (3) and (4) into a single op. That, however, might make the ops unusable by nfsd, which may well want to bypass the checks or do them elsewhere. Any thoughts? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 SECCLASS_CACHE. Right, the latter is reasonable. Okay... It looks like I want four security operations/hooks for cachefiles: (1) Check that a daemon can nominate a secid for use by the kernel to override the process subjective secid. (2) Set the secid mentioned in (1). (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). (4) Set the fscreate secid mentioned in (3). Now, it's possible to condense (1) and (2) into a single op, and condense (3) and (4) into a single op. That, however, might make the ops unusable by nfsd, which may well want to bypass the checks or do them elsewhere. Any thoughts? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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
create_files_as
}
The first allows:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__USE_AS_OVERRIDE,
NULL);
And the second something like:
avc_has_perm(tsec-sid, inode-sid,
SECCLASS_KERNEL_SERVICE,
KERNEL_SERVICE__CREATE_FILES_AS,
NULL);
Rather than specifically dedicating them to the cache, I made them general.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 are of SECCLASS_PROCESS rather than of SECCLASS_CACHE. Right, the latter is reasonable. Okay... It looks like I want four security operations/hooks for cachefiles: (1) Check that a daemon can nominate a secid for use by the kernel to override the process subjective secid. (2) Set the secid mentioned in (1). (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). (4) Set the fscreate secid mentioned in (3). Now, it's possible to condense (1) and (2) into a single op, 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. and condense (3) and (4) into a single op. That, however, might make the ops unusable by nfsd, which may well want to bypass the checks or do them elsewhere. Again, I don't think you're doing yourself any favors with a separate test operation. On (4) are you suggesting a third attribute value? There's the secid of the task originally, the secid you're going to use to do the access checks, and the secid you're going to set the file to on creation. Any thoughts? Let me see if I understand your current scheme. You want a (object) secid that is used to access the task. You want a (subject) secid that the task uses to accesses objects. You want a (newobject) secid that an object gets on creation. And you want them all to be distinct and settable. Did I get that right? Thank you. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 permission race because there's no locking. This may be different for other models. I was thinking of having steps (2) and (4) not do any checking, but rather assume that the caller has done the checks before calling the set routines, possibly by calling the hooks mentioned in (1) and (3). My main problem is that I don't know how NFSd wants to do things. I suppose there *ought* to be rules that say what NFSd is allowed to do. and condense (3) and (4) into a single op. That, however, might make the ops unusable by nfsd, which may well want to bypass the checks or do them elsewhere. Again, I don't think you're doing yourself any favors with a separate test operation. It doesn't matter to cachefiles, but it might matter to other users:-/ On (4) are you suggesting a third attribute value? There's the secid of the task originally, the secid you're going to use to do the access checks, and the secid you're going to set the file to on creation. That's correct. Let me summarise: (1) The daemon has an active process security ID (say A). When the daemon nominates an override process security ID (say B) to be used by the kernel, the cachefiles module asks the LSM to check that A is allowed to nominate B for this purpose. (2) The cachefiles module is given a path under which its cache exists. The directory at the base of this path has its own security ID (say C). cachefiles wants to create new files in the cache with the same security ID as that directory (ie. C). However, when cachefiles is creating files in the cache, the security of whatever process is doing the access will be overridden with B, so cachefiles asks the LSM to check that B is allowed create files as C. Note that this is an instantaneous check in the cache startup stage. This allows caching to be aborted early if the security policy does not permit B to create Cs. Technically this check is superfluous as it's re-checked each time a vfs_mkdir() or vfs_create() are called. Any thoughts? Let me see if I understand your current scheme. You want a (object) secid that is used to access the task. That depends on what you mean. cachefilesd (the daemon) will be run with a security label because there's a security model in place. I don't actually need to access the daemon, but the daemon does need to do things for which it requires permission grants. You want a (subject) secid that the task uses to accesses objects. Correct. This is used as an override by any task that accesses the cache indirectly through the cachefiles module. The cachefilesd daemon has its own secid with which it accesses the cache directly. The sets of permissions that must be granted by the module's override subjective secid and by the daemon's subjective secid aren't identical. You want a (newobject) secid that an object gets on creation. File and directory objects, yes. The cache is stored on disk as a collection of files and directories, each of which needs labelling. And you want them all to be distinct and settable. Well, they don't technically have to be different. The daemon and the module can be given the same secid, for instance. However, that secid then grants the daemon permission to anything the module can, and vice versa. The third secid is a file label rather than a process label, and so may or may not have to be different anyway, depending on the model. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 do I set it? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 do I set it? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 headers from those files, ala: > > svn co http://oss.tresys.com/repos/refpolicy/trunk refpolicy > > cd refpolicy/policy/flask > > vi security_classes access_vectors > > > > make > > make LINUX_D=/path/to/linux-2.6 tokern > > Does this require rebuilding and updating all the SELinux rpms to know about > the new class? Policy ultimately has to be updated in order to start writing allow rules based on the new class/perm. libselinux et al doesn't have to change. 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. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 http://oss.tresys.com/repos/refpolicy/trunk refpolicy > cd refpolicy/policy/flask > vi security_classes access_vectors > > make > make LINUX_D=/path/to/linux-2.6 tokern Does this require rebuilding and updating all the SELinux rpms to know about the new class? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 certain I > have a patch to add such kicking around somewhere. Already planned for 2.6.25, see: http://marc.info/?l=selinux=119973017423487=2 That is in the labeled networking tree. > (2) Make security_task_kernel_act_as() take a task_security struct and a > secID and just assign the latter to the former. I'm not sure it makes > sense to do any checks here, other than checking that under SELinux the > secID is of SECCLASS_PROCESS class. > > However, I need to write a check that the cachefilesd daemon is permitted to > nominate the secID it did. Can someone tell me how to do this? The obvious > way to do this is to add another PROCESS__xxx security permit specifically for > cachefiles, but that seems like a waste of a bit when there are only two spare > bits. > > avc_has_perm(daemon_tsec->sid, nominated_sid, >SECCLASS_PROCESS, PROCESS__CACHEFILES_USE, NULL); > > 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); > > 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 SECCLASS_CACHE. 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 http://oss.tresys.com/repos/refpolicy/trunk refpolicy cd refpolicy/policy/flask vi security_classes access_vectors make make LINUX_D=/path/to/linux-2.6 tokern Dan knows how to do that. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 see how to add a new security class. I can see that security classes are defined in various autogenerated header files, but autogenerated from what? The "This file is automatically generated. Do not edit." message at the top of these files seems to belie the fact they're actually checked in to GIT as is. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. (2) Make security_task_kernel_act_as() take a task_security struct and a secID and just assign the latter to the former. I'm not sure it makes sense to do any checks here, other than checking that under SELinux the secID is of SECCLASS_PROCESS class. However, I need to write a check that the cachefilesd daemon is permitted to nominate the secID it did. Can someone tell me how to do this? The obvious way to do this is to add another PROCESS__xxx security permit specifically for cachefiles, but that seems like a waste of a bit when there are only two spare bits. avc_has_perm(daemon_tsec->sid, nominated_sid, SECCLASS_PROCESS, PROCESS__CACHEFILES_USE, NULL); 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); 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 SECCLASS_CACHE. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. (2) Make security_task_kernel_act_as() take a task_security struct and a secID and just assign the latter to the former. I'm not sure it makes sense to do any checks here, other than checking that under SELinux the secID is of SECCLASS_PROCESS class. However, I need to write a check that the cachefilesd daemon is permitted to nominate the secID it did. Can someone tell me how to do this? The obvious way to do this is to add another PROCESS__xxx security permit specifically for cachefiles, but that seems like a waste of a bit when there are only two spare bits. avc_has_perm(daemon_tsec-sid, nominated_sid, SECCLASS_PROCESS, PROCESS__CACHEFILES_USE, NULL); 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); 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 SECCLASS_CACHE. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 see how to add a new security class. I can see that security classes are defined in various autogenerated header files, but autogenerated from what? The This file is automatically generated. Do not edit. message at the top of these files seems to belie the fact they're actually checked in to GIT as is. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 certain I have a patch to add such kicking around somewhere. Already planned for 2.6.25, see: http://marc.info/?l=selinuxm=119973017423487w=2 That is in the labeled networking tree. (2) Make security_task_kernel_act_as() take a task_security struct and a secID and just assign the latter to the former. I'm not sure it makes sense to do any checks here, other than checking that under SELinux the secID is of SECCLASS_PROCESS class. However, I need to write a check that the cachefilesd daemon is permitted to nominate the secID it did. Can someone tell me how to do this? The obvious way to do this is to add another PROCESS__xxx security permit specifically for cachefiles, but that seems like a waste of a bit when there are only two spare bits. avc_has_perm(daemon_tsec-sid, nominated_sid, SECCLASS_PROCESS, PROCESS__CACHEFILES_USE, NULL); 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); 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 SECCLASS_CACHE. 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 http://oss.tresys.com/repos/refpolicy/trunk refpolicy cd refpolicy/policy/flask vi security_classes access_vectors add new class to end make make LINUX_D=/path/to/linux-2.6 tokern Dan knows how to do that. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 http://oss.tresys.com/repos/refpolicy/trunk refpolicy cd refpolicy/policy/flask vi security_classes access_vectors add new class to end make make LINUX_D=/path/to/linux-2.6 tokern Does this require rebuilding and updating all the SELinux rpms to know about the new class? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 headers from those files, ala: svn co http://oss.tresys.com/repos/refpolicy/trunk refpolicy cd refpolicy/policy/flask vi security_classes access_vectors add new class to end make make LINUX_D=/path/to/linux-2.6 tokern Does this require rebuilding and updating all the SELinux rpms to know about the new class? Policy ultimately has to be updated in order to start writing allow rules based on the new class/perm. libselinux et al doesn't have to change. 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. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 not sure, but I think that you could do this *much* easier in > AppArmor using change_profile to switch the NFS Daemon to the profile of > the requesting process. That still leaves some problems: NFS Daemon? NFS quite often runs in the context of whichever process issued, say, a read syscall. It's at this point the cachefiles needs to run, and using change_profile is I suspect not an option there. Remember: you can't change the objective profile of the aforementioned process, hence the act_as pointer. That said, I don't know what change_profile does. > However, it seems to me that you have the same problem with SELinux: > what do you do if the domain/type of the requesting process does not > exist on the NFS server? How do you ensure a uniform name space of types? I'm not sure what you're getting at. The security NFS uses to access the server is separate from the security that cachefiles uses to access the cache. > > 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, given the daemon's own security context? That > > seems entirely reasonable to me. > > > That semantically maps well to the AppArmor change_profile() API, so > conceptually it should work. Okay. > It would be easier if you did that in user space instead of in the kernel, Do what in userspace? Parse the context? Validate the context? Or change the context? > I don't know if it causes a problem to attempt to kind-of call > change_profile() from within the kernel. Notably, change_profile can fail, > so what does your kernel module do when the attempt to change security > context fails? The cache aborts and all subsequent operations on that cache bounce and go to the server instead. The change of context cannot be done in userspace because to get to a userspace capable of attempting this operation would itself require a change of context. Besides, it'd also be inefficient, probably horribly so, to do all caching ops in userspace. What I need is an LSM operation to change a task_security struct to have a specified context. I can then use the task_security struct in all future cache ops on a cache by pointing task->act_as at it. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. > >> > > All your code has to do is invoke a function provided by libselinux. If > > at some later time a liblsm is introduced that provides a common > > front-end to a libselinux, libsmack, ..., then you can use that. But it > > doesn't exist today. But it all just becomes a simple function call > > regardless. > > > libapparmor exists. It only had one API, and now it has 2, but just 2 > versions on the same concept (change_hat and change_profile). > > This is the API for change_hat http://man-wiki.net/index.php/2:change_hat > > What does the corresponding API in SELinux look like? The SELinux API for changing context is described in: http://linux.die.net/man/3/setcon However, setting the current context (SELinux) or profile (AppArmor) for a userspace task doesn't really provide the functionality required here for cachefiles, nor does it solve the (different, yet related) nfsd problem. cachefiles is a kernel module that needs to assume a different set of credentials for its internal accesses to the cache files it manages when a userspace process tries to access a file that has been cached, as the userspace process in whose context it is operating may (and should) lack direct permission to those cache files. The userspace API being talked about is simply how one configures the credentials to be used by cachefiles kernel module for its internal accesses, and is done up front when cachefiles is configured to create a cache. The internal switching of the active set of credentials is done via a kernel-internal API (or just by switching the pointer to the credential structure previously set up) when the cachefiles kernel module wants to access a cache file. Further, when this internal switching occurs, we have to be careful that there are no user-visible side effects on the current task - no change in how others may operate on that task e.g. signal permission checks or on how the task appears to others e.g. via /proc. Neither change_hat nor setcon helps with that problem. For AppArmor, I suspect that you just want the cachefiles kernel module to act as unconfined for its internal accesses, nothing more. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. All your code has to do is invoke a function provided by libselinux. If at some later time a liblsm is introduced that provides a common front-end to a libselinux, libsmack, ..., then you can use that. But it doesn't exist today. But it all just becomes a simple function call regardless. libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? The SELinux API for changing context is described in: http://linux.die.net/man/3/setcon However, setting the current context (SELinux) or profile (AppArmor) for a userspace task doesn't really provide the functionality required here for cachefiles, nor does it solve the (different, yet related) nfsd problem. cachefiles is a kernel module that needs to assume a different set of credentials for its internal accesses to the cache files it manages when a userspace process tries to access a file that has been cached, as the userspace process in whose context it is operating may (and should) lack direct permission to those cache files. The userspace API being talked about is simply how one configures the credentials to be used by cachefiles kernel module for its internal accesses, and is done up front when cachefiles is configured to create a cache. The internal switching of the active set of credentials is done via a kernel-internal API (or just by switching the pointer to the credential structure previously set up) when the cachefiles kernel module wants to access a cache file. Further, when this internal switching occurs, we have to be careful that there are no user-visible side effects on the current task - no change in how others may operate on that task e.g. signal permission checks or on how the task appears to others e.g. via /proc. Neither change_hat nor setcon helps with that problem. For AppArmor, I suspect that you just want the cachefiles kernel module to act as unconfined for its internal accesses, nothing more. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 not sure, but I think that you could do this *much* easier in AppArmor using change_profile to switch the NFS Daemon to the profile of the requesting process. That still leaves some problems: NFS Daemon? NFS quite often runs in the context of whichever process issued, say, a read syscall. It's at this point the cachefiles needs to run, and using change_profile is I suspect not an option there. Remember: you can't change the objective profile of the aforementioned process, hence the act_as pointer. That said, I don't know what change_profile does. However, it seems to me that you have the same problem with SELinux: what do you do if the domain/type of the requesting process does not exist on the NFS server? How do you ensure a uniform name space of types? I'm not sure what you're getting at. The security NFS uses to access the server is separate from the security that cachefiles uses to access the cache. 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, given the daemon's own security context? That seems entirely reasonable to me. That semantically maps well to the AppArmor change_profile() API, so conceptually it should work. Okay. It would be easier if you did that in user space instead of in the kernel, Do what in userspace? Parse the context? Validate the context? Or change the context? I don't know if it causes a problem to attempt to kind-of call change_profile() from within the kernel. Notably, change_profile can fail, so what does your kernel module do when the attempt to change security context fails? The cache aborts and all subsequent operations on that cache bounce and go to the server instead. The change of context cannot be done in userspace because to get to a userspace capable of attempting this operation would itself require a change of context. Besides, it'd also be inefficient, probably horribly so, to do all caching ops in userspace. What I need is an LSM operation to change a task_security struct to have a specified context. I can then use the task_security struct in all future cache ops on a cache by pointing task-act_as at it. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 probably less of a pain if you consider that Casey's
security scheme is Smack.
> > All your code has to do is invoke a function provided by libselinux. If
> > at some later time a liblsm is introduced that provides a common
> > front-end to a libselinux, libsmack, ..., then you can use that. But it
> > doesn't exist today. But it all just becomes a simple function call
> > regardless.
> >
> libapparmor exists. It only had one API, and now it has 2, but just 2
> versions on the same concept (change_hat and change_profile).
>
> This is the API for change_hat http://man-wiki.net/index.php/2:change_hat
>
> What does the corresponding API in SELinux look like?
The POSIX mac_set_proc(mac_t label) might work for this interface.
Sets the current process MAC attribute, if appropriate. The Smack
implementation would be pretty easy:
typedef char * mac_t;
int mac_set_proc(mac_t label)
{
int fd;
int rc;
rc = strlen(label);
if (rc > SMACK_MAX_LABEL_LEN)
return -1;
fd = open("/proc/self/attr/current", O_RDWR);
if (fd < 0)
return -1;
rc = write(fd, label, rc);
close(fd);
if (rc < 0)
return -1;
return 0;
}
Casey Schaufler
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 by libselinux. If > at some later time a liblsm is introduced that provides a common > front-end to a libselinux, libsmack, ..., then you can use that. But it > doesn't exist today. But it all just becomes a simple function call > regardless. > libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 >> objections/concerns about it. >> > So, basically, userspace programs (outside of security tools) aren't supposed > to need access to the security infrastructure? > That depends on your LSM model. Under SELinux, lots of programs need access to the security infrastructure to set the label to something other than the default label. Under AppArmor, there is no concept of a label, and not much need for programs to access the security infrastructure. So far, AppArmor has two API's into the kernel: change_hat() and change_profile(). Both of them are used to change the security context of the calling process. Naturally they are subject to policy restrictions of what you get to change to. They are largely intended to be used by applications servers (think of Java servlets) to change into a security context associated with a servlet rather than putting all the hosted applications in the application server's context. I'm unclear on whether SELinux has an analogous facility. I've been told that the concept is anathema, and also that there is a similar facility in SELinux, but without the corresponding user-space components that AppArmor provides (mod_apparmor for Apache, and a similar module for Tomcat). Going way up to the top of the threat for 08/28, you say you want to do this: 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. > > 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 not sure, but I think that you could do this *much* easier in AppArmor using change_profile to switch the NFS Daemon to the profile of the requesting process. That still leaves some problems: * The profile of the requesting process has to exist on the NFS server, and it may not. * You need a uniform name space of profiles, and you definitely don't have that. However, it seems to me that you have the same problem with SELinux: what do you do if the domain/type of the requesting process does not exist on the NFS server? How do you ensure a uniform name space of types? >>> Is linking against libselinux is a viable option if it's not available under >>> all LSM models? Is it available under all LSM models? Perhaps Casey can >>> answer this one. >>> >> Nope, they would all have their own libraries, if they have a library at >> all. But that isn't your problem >> > 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. > There is little correspondence between AppArmor and SELinux, but one point of correspondence is that an AA "profile" is quite similar to the SELinux notion of a domain as applied to a process. In the Targeted Policy, they are used the same way too. I could imagine a small (growing) generic library that mapped onto SELinux and AppArmor APIs for changing security context. >> Why are you opposed to having userspace determine the context and write it >> to a cachefiles interface, >> > Because, from what I gather, that means my userspace program needs to do > something different, depending on the security model that's currently in force > on a system. Yes, that's absolutely true: if you want to manipulate the security system, you have to actually call it in terms that the security system will understand. > Furthermore, I would have to have separate code, as far as I > know, for each security model as there's no commonality in userspace. > Yep. If there was a common user space, ten there really wouldn't need to be separate LSMs. This is a fundamental problem: the security systems export rather different semantics, so there cannot be a truly generic user space, just some band aids that provide a klude to access the bits that kind of have some overlap. > 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, given the daemon's own security context? That seems entirely > reasonable to me. > That semantically maps well to the AppArmor change_profile() API, so conceptually it should work. It would be easier if you
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 objections/concerns about it. So, basically, userspace programs (outside of security tools) aren't supposed to need access to the security infrastructure? That depends on your LSM model. Under SELinux, lots of programs need access to the security infrastructure to set the label to something other than the default label. Under AppArmor, there is no concept of a label, and not much need for programs to access the security infrastructure. So far, AppArmor has two API's into the kernel: change_hat() and change_profile(). Both of them are used to change the security context of the calling process. Naturally they are subject to policy restrictions of what you get to change to. They are largely intended to be used by applications servers (think of Java servlets) to change into a security context associated with a servlet rather than putting all the hosted applications in the application server's context. I'm unclear on whether SELinux has an analogous facility. I've been told that the concept is anathema, and also that there is a similar facility in SELinux, but without the corresponding user-space components that AppArmor provides (mod_apparmor for Apache, and a similar module for Tomcat). Going way up to the top of the threat for 08/28, you say you want to do this: 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. 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 not sure, but I think that you could do this *much* easier in AppArmor using change_profile to switch the NFS Daemon to the profile of the requesting process. That still leaves some problems: * The profile of the requesting process has to exist on the NFS server, and it may not. * You need a uniform name space of profiles, and you definitely don't have that. However, it seems to me that you have the same problem with SELinux: what do you do if the domain/type of the requesting process does not exist on the NFS server? How do you ensure a uniform name space of types? Is linking against libselinux is a viable option if it's not available under all LSM models? Is it available under all LSM models? Perhaps Casey can answer this one. Nope, they would all have their own libraries, if they have a library at all. But that isn't your problem 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. There is little correspondence between AppArmor and SELinux, but one point of correspondence is that an AA profile is quite similar to the SELinux notion of a domain as applied to a process. In the Targeted Policy, they are used the same way too. I could imagine a small (growing) generic library that mapped onto SELinux and AppArmor APIs for changing security context. Why are you opposed to having userspace determine the context and write it to a cachefiles interface, Because, from what I gather, that means my userspace program needs to do something different, depending on the security model that's currently in force on a system. Yes, that's absolutely true: if you want to manipulate the security system, you have to actually call it in terms that the security system will understand. Furthermore, I would have to have separate code, as far as I know, for each security model as there's no commonality in userspace. Yep. If there was a common user space, ten there really wouldn't need to be separate LSMs. This is a fundamental problem: the security systems export rather different semantics, so there cannot be a truly generic user space, just some band aids that provide a klude to access the bits that kind of have some overlap. 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, given the daemon's own security context? That seems entirely reasonable to me. That semantically maps well to the AppArmor change_profile() API, so conceptually it should work. It would be easier if you did that in user space instead of in the kernel, I don't know if it causes
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 by libselinux. If at some later time a liblsm is introduced that provides a common front-end to a libselinux, libsmack, ..., then you can use that. But it doesn't exist today. But it all just becomes a simple function call regardless. libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 probably less of a pain if you consider that Casey's
security scheme is Smack.
All your code has to do is invoke a function provided by libselinux. If
at some later time a liblsm is introduced that provides a common
front-end to a libselinux, libsmack, ..., then you can use that. But it
doesn't exist today. But it all just becomes a simple function call
regardless.
libapparmor exists. It only had one API, and now it has 2, but just 2
versions on the same concept (change_hat and change_profile).
This is the API for change_hat http://man-wiki.net/index.php/2:change_hat
What does the corresponding API in SELinux look like?
The POSIX mac_set_proc(mac_t label) might work for this interface.
Sets the current process MAC attribute, if appropriate. The Smack
implementation would be pretty easy:
typedef char * mac_t;
int mac_set_proc(mac_t label)
{
int fd;
int rc;
rc = strlen(label);
if (rc SMACK_MAX_LABEL_LEN)
return -1;
fd = open(/proc/self/attr/current, O_RDWR);
if (fd 0)
return -1;
rc = write(fd, label, rc);
close(fd);
if (rc 0)
return -1;
return 0;
}
Casey Schaufler
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 affect only the cache instance it is attached
to; similarly, any status data you read only refers to that one cache
instance.
Closing the file descriptor makes the cache go away as far as the kernel is
concerned. The cachefiles daemon retains its cache dev file descriptor for
the lifetime of the daemon.
> What if there is a conflict between multiple tasks asking for the same
> cache?
As far as the cache daemon is concerned, the file descriptor is its handle to
the cache so the conflict does not arise.
> secid is being applied as the acting context for the cachefiles kernel
> module, so the above makes sense, even though there isn't really any
> "object" in view here. Abstractly, the question we are asking above is:
>
> Can this task set the context of the cachefiles kernel module to this
> value?
So the following (taken from cachefilesd.te):
allow cachefilesd_t cachefiles_var_t : file { getattr rename unlink };
says, for example, allow:
avc_has_perm("cachefilesd_t",
"cachefiles_var_t",
SECCLASS_FILE,
FILE__RENAME,
...);
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 /dev/cachefiles has its own unique > label (cachefiles_dev_t). That lets you control who can use the interface at all, but not what operations they can invoke on it. > > Could just be a single 'setcontext' permission if that is all you want to > > control distinctly, or could be a permission per operation. > > There is only one operation that makes sense to have a permission: "set > context and begin caching". > > All the other operations on a file descriptor attached to /dev/cachfiles are > necessary for there to be a managed cache at all, and given that you've > managed to open /dev/cachefiles that's sufficient access for those, I think. Do any of the interfaces allow a task to act on a cache other than one it has created? How does the task identify the desired cache? What if there is a conflict between multiple tasks asking for the same cache? > > If the latter, you don't really need a label for the object, and can > > just use the supplied context/secid as the object of the permission > > check, ala: > > rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES, > > CACHEFILES__SETCONTEXT); > > Ummm. I was under the impression that the target SID had to be a member of > target class. Not necessarily. secid is being applied as the acting context for the cachefiles kernel module, so the above makes sense, even though there isn't really any "object" in view here. Abstractly, the question we are asking above is: Can this task set the context of the cachefiles kernel module to this value? -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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). > Could just be a single 'setcontext' permission if that is all you want to > control distinctly, or could be a permission per operation. There is only one operation that makes sense to have a permission: "set context and begin caching". All the other operations on a file descriptor attached to /dev/cachfiles are necessary for there to be a managed cache at all, and given that you've managed to open /dev/cachefiles that's sufficient access for those, I think. > If the latter, you don't really need a label for the object, and can > just use the supplied context/secid as the object of the permission > check, ala: > rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES, > CACHEFILES__SETCONTEXT); Ummm. I was under the impression that the target SID had to be a member of target class. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 controlling an operation > > on the /dev/cachefiles interface that only applies to cachefiles > > internal operations, so making a cachefiles class seems reasonable. > > Can you specify what sort of permissions you're thinking of providing for > tasks to operate on this class? They would correspond with the operations provided by the /dev/cachefiles interface, at the granularity you want to support distinctions to be made. Could just be a single 'setcontext' permission if that is all you want to control distinctly, or could be a permission per operation. > Can an object of this class 'operate' on > other objects, or can only process-class objects do that? In this case, I wouldn't expect a cachefiles object to act on anything else. Some objects are also used as subjects, especially in the networking arena. > How does an object of this class acquire a label? What is an object of this > class? Is it a "cache"? Or were you thinking of a "module"? I was thinking the latter since the only goal was to control what contexts could be set by a given task, but you could support per-cache "objects" with their own labels (in which case the label would likely be determined from the creating task). If the latter, you don't really need a label for the object, and can just use the supplied context/secid as the object of the permission check, ala: rc = avc_has_perm(tsec->sid, secid, SECCLASS_CACHEFILES, CACHEFILES__SETCONTEXT); If the former, then you'd need more than one check, as you then have to check whether the task can act on the cache in question, and then check whether it can set the context for that cache to the specified value. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 sounds nicely genericisable, perhaps even for any LSM. /usr/bin/lsm-get-context cachefiles It does have to be able to come up with different contexts for different caches, but that can be controlled by changing the name supplied to it. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 modifiable file. Is there a program I could > make cachefiles run directly and capture the output of that could give me the > info I want? 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. > > then run it again maybe upon a policy update or if the user selects a > > different policy. > > How do I do that? -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 only applies to cachefiles > internal operations, so making a cachefiles class seems reasonable. Can you specify what sort of permissions you're thinking of providing for tasks to operate on this class? Can an object of this class 'operate' on other objects, or can only process-class objects do that? How does an object of this class acquire a label? What is an object of this class? Is it a "cache"? Or were you thinking of a "module"? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 map a context string to a > > secid. > > Validate as in check it's a valid string? Okay, I see that. Yes. > > It wouldn't perform any permission check, as the caller might a > > kernel-internal user that is just mapping back and forth like current users > > of security_secid_to_secctx, or it might be something that ultimately > > originated from userspace but the hook has no way of knowing why or what set > > of checks would be appropriate. You'd need a more specific hook for the > > authorization, one that would perform a permission check, e.g. an > > avc_has_perm() call. Which likely requires defining a new class and > > permissions for your cachefiles kernel interface. > > Hmmm... This is sounding very not-simple. I don't know how to do this. I > can probably guess the kernel side by looking at how SECCLASS_KEY is done, but > it sounds like it involves changes to the userspace policy processing tools > too. Not the tools, just the policy definitions. Dan can help with that. You add the definitions to the policy, then there is a script to regenerate the SELinux kernel headers that #define the SECCLASS_ and permission values. > It also sounds a bit like overkill, but if it's the right way then I guess it > has to be done. > > What does the security class represent in this case? And can it be > generalised > to apply to non-cachefiles stuff too? 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 only applies to cachefiles internal operations, so making a cachefiles class seems reasonable. If this was instead just a generic "set my acting context to " operation, then it could be a generic /proc/self/attr/active interface with an generic implementation and permission check, but here we aren't setting the active context of the cachefilesd daemon but rather of the cachefiles kernel module. The other approach that I suggested a long time ago is to exempt the cachefiles kernel module internal operations from SELinux permission checks altogether by setting some task flag when performing those operations and checking for that flag either on entry to the security_ static inlines, similar to the inode private flag, or within SELinux itself. Rationale being that the cachefiles kernel module can already do what it wants and the SELinux permission checks are really about controlling what userspace can do. Then we don't have to invent a context for the kernel module at all or worry about subtle breakage when some permission is missing from its policy. > > > Or is it that I need something that takes a secctx, converts it to a secid > > > and authorises its use all in one go? If it's this, why can't that be > > > rolles into security_task_kernel_act_as()? That sets up a task_security > > > struct which is then switched in and out without consultation of the LSM. > > > > I was under the impression that security_task_kernel_act_as() was being used > > to switch the current task to an acting context, not to initially set up a > > struct for later use. > > Definitely the latter. I guess I wasn't very clear in the patch description. > It also sounds like I need to adjust the naming of certain functions. > > > If you go with the latter approach, then what is the lifecycle on that > > struct? > > (1) You create a new task_security struct > > (2) You fill in the fsuid, fsgid, etc. > > (3) You request that the LSM security pointer in it be set to point to the > context you want (at the moment this is done by attempting a transition > from the daemon's context): > > ret = security_transition_sid(dtsec->sid, SECINITSID_KERNEL, > SECCLASS_PROCESS, ); > > and, in the current code, it returns an error if you're not allowed to do > that. But instead you'd ask it to set a specific context, and it'd set > that if you're permitted to do that, and give you an error if you're not. > > (4) You then use the task_security at will to override the task->act_as > pointer in whatever task(s) you're operating on behalf of at the moment. > > (5) When you cease operating on the behalf of a task, you revert its act_as > pointer and drop a reference to your task_security struct. > > (6) When the last ref to the task_security struct goes away, the LSM data > attached to it is released, as are its groups and keyrings. > > > BTW, it gets a little confusing with your use of task_security for the full > > task security state vs our
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 map a context string to a secid. Validate as in check it's a valid string? Okay, I see that. Yes. It wouldn't perform any permission check, as the caller might a kernel-internal user that is just mapping back and forth like current users of security_secid_to_secctx, or it might be something that ultimately originated from userspace but the hook has no way of knowing why or what set of checks would be appropriate. You'd need a more specific hook for the authorization, one that would perform a permission check, e.g. an avc_has_perm() call. Which likely requires defining a new class and permissions for your cachefiles kernel interface. Hmmm... This is sounding very not-simple. I don't know how to do this. I can probably guess the kernel side by looking at how SECCLASS_KEY is done, but it sounds like it involves changes to the userspace policy processing tools too. Not the tools, just the policy definitions. Dan can help with that. You add the definitions to the policy, then there is a script to regenerate the SELinux kernel headers that #define the SECCLASS_ and permission values. It also sounds a bit like overkill, but if it's the right way then I guess it has to be done. What does the security class represent in this case? And can it be generalised to apply to non-cachefiles stuff too? 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 only applies to cachefiles internal operations, so making a cachefiles class seems reasonable. If this was instead just a generic set my acting context to value operation, then it could be a generic /proc/self/attr/active interface with an generic implementation and permission check, but here we aren't setting the active context of the cachefilesd daemon but rather of the cachefiles kernel module. The other approach that I suggested a long time ago is to exempt the cachefiles kernel module internal operations from SELinux permission checks altogether by setting some task flag when performing those operations and checking for that flag either on entry to the security_ static inlines, similar to the inode private flag, or within SELinux itself. Rationale being that the cachefiles kernel module can already do what it wants and the SELinux permission checks are really about controlling what userspace can do. Then we don't have to invent a context for the kernel module at all or worry about subtle breakage when some permission is missing from its policy. Or is it that I need something that takes a secctx, converts it to a secid and authorises its use all in one go? If it's this, why can't that be rolles into security_task_kernel_act_as()? That sets up a task_security struct which is then switched in and out without consultation of the LSM. I was under the impression that security_task_kernel_act_as() was being used to switch the current task to an acting context, not to initially set up a struct for later use. Definitely the latter. I guess I wasn't very clear in the patch description. It also sounds like I need to adjust the naming of certain functions. If you go with the latter approach, then what is the lifecycle on that struct? (1) You create a new task_security struct (2) You fill in the fsuid, fsgid, etc. (3) You request that the LSM security pointer in it be set to point to the context you want (at the moment this is done by attempting a transition from the daemon's context): ret = security_transition_sid(dtsec-sid, SECINITSID_KERNEL, SECCLASS_PROCESS, ksid); and, in the current code, it returns an error if you're not allowed to do that. But instead you'd ask it to set a specific context, and it'd set that if you're permitted to do that, and give you an error if you're not. (4) You then use the task_security at will to override the task-act_as pointer in whatever task(s) you're operating on behalf of at the moment. (5) When you cease operating on the behalf of a task, you revert its act_as pointer and drop a reference to your task_security struct. (6) When the last ref to the task_security struct goes away, the LSM data attached to it is released, as are its groups and keyrings. BTW, it gets a little confusing with your use of task_security for the full task security state vs our existing use of task_security_struct within SELinux for the task's LSM security blob. I know.
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 modifiable file. Is there a program I could make cachefiles run directly and capture the output of that could give me the info I want? 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. then run it again maybe upon a policy update or if the user selects a different policy. How do I do that? -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 only applies to cachefiles internal operations, so making a cachefiles class seems reasonable. Can you specify what sort of permissions you're thinking of providing for tasks to operate on this class? Can an object of this class 'operate' on other objects, or can only process-class objects do that? How does an object of this class acquire a label? What is an object of this class? Is it a cache? Or were you thinking of a module? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 sounds nicely genericisable, perhaps even for any LSM. /usr/bin/lsm-get-context cachefiles It does have to be able to come up with different contexts for different caches, but that can be controlled by changing the name supplied to it. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 controlling an operation on the /dev/cachefiles interface that only applies to cachefiles internal operations, so making a cachefiles class seems reasonable. Can you specify what sort of permissions you're thinking of providing for tasks to operate on this class? They would correspond with the operations provided by the /dev/cachefiles interface, at the granularity you want to support distinctions to be made. Could just be a single 'setcontext' permission if that is all you want to control distinctly, or could be a permission per operation. Can an object of this class 'operate' on other objects, or can only process-class objects do that? In this case, I wouldn't expect a cachefiles object to act on anything else. Some objects are also used as subjects, especially in the networking arena. How does an object of this class acquire a label? What is an object of this class? Is it a cache? Or were you thinking of a module? I was thinking the latter since the only goal was to control what contexts could be set by a given task, but you could support per-cache objects with their own labels (in which case the label would likely be determined from the creating task). If the latter, you don't really need a label for the object, and can just use the supplied context/secid as the object of the permission check, ala: rc = avc_has_perm(tsec-sid, secid, SECCLASS_CACHEFILES, CACHEFILES__SETCONTEXT); If the former, then you'd need more than one check, as you then have to check whether the task can act on the cache in question, and then check whether it can set the context for that cache to the specified value. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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). Could just be a single 'setcontext' permission if that is all you want to control distinctly, or could be a permission per operation. There is only one operation that makes sense to have a permission: set context and begin caching. All the other operations on a file descriptor attached to /dev/cachfiles are necessary for there to be a managed cache at all, and given that you've managed to open /dev/cachefiles that's sufficient access for those, I think. If the latter, you don't really need a label for the object, and can just use the supplied context/secid as the object of the permission check, ala: rc = avc_has_perm(tsec-sid, secid, SECCLASS_CACHEFILES, CACHEFILES__SETCONTEXT); Ummm. I was under the impression that the target SID had to be a member of target class. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 /dev/cachefiles has its own unique label (cachefiles_dev_t). That lets you control who can use the interface at all, but not what operations they can invoke on it. Could just be a single 'setcontext' permission if that is all you want to control distinctly, or could be a permission per operation. There is only one operation that makes sense to have a permission: set context and begin caching. All the other operations on a file descriptor attached to /dev/cachfiles are necessary for there to be a managed cache at all, and given that you've managed to open /dev/cachefiles that's sufficient access for those, I think. Do any of the interfaces allow a task to act on a cache other than one it has created? How does the task identify the desired cache? What if there is a conflict between multiple tasks asking for the same cache? If the latter, you don't really need a label for the object, and can just use the supplied context/secid as the object of the permission check, ala: rc = avc_has_perm(tsec-sid, secid, SECCLASS_CACHEFILES, CACHEFILES__SETCONTEXT); Ummm. I was under the impression that the target SID had to be a member of target class. Not necessarily. secid is being applied as the acting context for the cachefiles kernel module, so the above makes sense, even though there isn't really any object in view here. Abstractly, the question we are asking above is: Can this task set the context of the cachefiles kernel module to this value? -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 affect only the cache instance it is attached
to; similarly, any status data you read only refers to that one cache
instance.
Closing the file descriptor makes the cache go away as far as the kernel is
concerned. The cachefiles daemon retains its cache dev file descriptor for
the lifetime of the daemon.
What if there is a conflict between multiple tasks asking for the same
cache?
As far as the cache daemon is concerned, the file descriptor is its handle to
the cache so the conflict does not arise.
secid is being applied as the acting context for the cachefiles kernel
module, so the above makes sense, even though there isn't really any
object in view here. Abstractly, the question we are asking above is:
Can this task set the context of the cachefiles kernel module to this
value?
So the following (taken from cachefilesd.te):
allow cachefilesd_t cachefiles_var_t : file { getattr rename unlink };
says, for example, allow:
avc_has_perm(cachefilesd_t,
cachefiles_var_t,
SECCLASS_FILE,
FILE__RENAME,
...);
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 directly and capture the output of that could give me the info I want? > then run it again maybe upon a policy update or if the user selects a > different policy. How do I do that? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 factors outside the LSM may be important, too. As Stephen > points out elsewhere, Smack will require you have particular capabilities > (CAP_MAC_OVERRIDE, CAP_MAC_ADMIN) while a DAC LSM may require > CAP_DAC_OVERRIDE. For what? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 valid string? Okay, I see that. > It wouldn't perform any permission check, as the caller might a > kernel-internal user that is just mapping back and forth like current users > of security_secid_to_secctx, or it might be something that ultimately > originated from userspace but the hook has no way of knowing why or what set > of checks would be appropriate. You'd need a more specific hook for the > authorization, one that would perform a permission check, e.g. an > avc_has_perm() call. Which likely requires defining a new class and > permissions for your cachefiles kernel interface. Hmmm... This is sounding very not-simple. I don't know how to do this. I can probably guess the kernel side by looking at how SECCLASS_KEY is done, but it sounds like it involves changes to the userspace policy processing tools too. It also sounds a bit like overkill, but if it's the right way then I guess it has to be done. What does the security class represent in this case? And can it be generalised to apply to non-cachefiles stuff too? > > Or is it that I need something that takes a secctx, converts it to a secid > > and authorises its use all in one go? If it's this, why can't that be > > rolles into security_task_kernel_act_as()? That sets up a task_security > > struct which is then switched in and out without consultation of the LSM. > > I was under the impression that security_task_kernel_act_as() was being used > to switch the current task to an acting context, not to initially set up a > struct for later use. Definitely the latter. I guess I wasn't very clear in the patch description. It also sounds like I need to adjust the naming of certain functions. > If you go with the latter approach, then what is the lifecycle on that > struct? (1) You create a new task_security struct (2) You fill in the fsuid, fsgid, etc. (3) You request that the LSM security pointer in it be set to point to the context you want (at the moment this is done by attempting a transition from the daemon's context): ret = security_transition_sid(dtsec->sid, SECINITSID_KERNEL, SECCLASS_PROCESS, ); and, in the current code, it returns an error if you're not allowed to do that. But instead you'd ask it to set a specific context, and it'd set that if you're permitted to do that, and give you an error if you're not. (4) You then use the task_security at will to override the task->act_as pointer in whatever task(s) you're operating on behalf of at the moment. (5) When you cease operating on the behalf of a task, you revert its act_as pointer and drop a reference to your task_security struct. (6) When the last ref to the task_security struct goes away, the LSM data attached to it is released, as are its groups and keyrings. > BTW, it gets a little confusing with your use of task_security for the full > task security state vs our existing use of task_security_struct within > SELinux for the task's LSM security blob. I know. I thought about it quite a bit, but the problem is there's so much overloading of various words (eg: security, context), and I wanted to avoid struct cred for various other reasons. > I suppose ours could be renamed to task_selinux. Better still, perhaps, would be to prefix things with selinux_ to make it namespace clean. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 separate /sys/cachefiles file) for setting the cache context as there may be several caches instantiated simply by opening /dev/cachefiles several times and retaining all the file descriptors involved. I meant this as information only. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 the magic > secctx that cachefiles will use instead of the secctx that the task > would have otherwise. I don't think we're talking about recomputing > it on every access, I think David is looking for the blunderbuss > secctx that he can use any time he needs one. Indeed. The way I do it is: (1) The daemon opens /dev/cachefiles to being an instance of a cache. (2) The daemon negotiates a security context for the module to use. (3) The security context is place in a task_security structure. (4) This task_security struct is attached temporarily to task->act_as each time any task attempts to access the cache through the module. (5) The task_security struct is discarded when the file descriptor that was created in (1) is closed and the cache is withdrawn at the same time. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 cachefileselinuxcontext (or > > > > cachefilesspiffylsmcontext) up in userspace. If you're going to > > > > rely on userspace applications for policy enforcement they need > > > > to be good enough to count on after all. > > > > > > It can't be done in userspace, otherwise someone using the cachefilesd > > > interface can pass an arbitrary context up. > > > > Yes, but I would expect that interface to be protected (owned by root, > > mode 0400). If /dev/cachefiles has to be publicly accessable make it > > a privileged ioctl. > > Uid 0 != CAP_MAC_OVERRIDE if you configure file caps and such. 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 the magic secctx that cachefiles will use instead of the secctx that the task would have otherwise. I don't think we're talking about recomputing it on every access, I think David is looking for the blunderbuss secctx that he can use any time he needs one. And it would be CAP_MAC_ADMIN, since you're changing the MAC characteristics of the system, not doing an access check. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 > > > cachefilesspiffylsmcontext) up in userspace. If you're going to > > > rely on userspace applications for policy enforcement they need > > > to be good enough to count on after all. > > > > It can't be done in userspace, otherwise someone using the cachefilesd > > interface can pass an arbitrary context up. > > Yes, but I would expect that interface to be protected (owned by root, > mode 0400). If /dev/cachefiles has to be publicly accessable make it > a privileged ioctl. Uid 0 != CAP_MAC_OVERRIDE if you configure file caps and such. > > The security context has to be > > passed across the file descriptor attached to /dev/cachefiles along with the > > other configuration parameters as a text string. > > I got that. > > > 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. > > > Casey Schaufler > [EMAIL PROTECTED] -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 applications for policy enforcement they need > > to be good enough to count on after all. > > It can't be done in userspace, otherwise someone using the cachefilesd > interface can pass an arbitrary context up. Yes, but I would expect that interface to be protected (owned by root, mode 0400). If /dev/cachefiles has to be publicly accessable make it a privileged ioctl. > The security context has to be > passed across the file descriptor attached to /dev/cachefiles along with the > other configuration parameters as a text string. I got that. > 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. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 it by the > > cachefilesd process. And then the security_task_kernel_act_as() hook > > just takes the secid as input rather than the task struct of the daemon, > > and applies it. At that point, nfsd can use the same mechanism for > > setting the acting SID based on the client process after doing its own > > authorization. > > I thought using secids was verboten as it made things too specific. I have argued that in the past. I'm reasonably convinced that I have lost that argument at least for the immediate future as audit, usb, and networking are all dependent on them. I can't image an LSM that manages to avoid them, at least for the short term. If secid's are ever expundged from the kernel cachefiles will require reeducation, but that will be a minor effort. > Have you example code for the security hook you mention? I'm not sure I > understand why security_secctx_to_secid() is not sufficient. > > Or is it that I need something that takes a secctx, converts it to a secid > and > authorises its use all in one go? > If it's this, why can't that be rolles > into > security_task_kernel_act_as()? That sets up a task_security struct which is > then switched in and out without consultation of the LSM. It would seem to me that security_secctx_to_secid() ought to suffice if the application code was written correctly. Be aware that factors outside the LSM may be important, too. As Stephen points out elsewhere, Smack will require you have particular capabilities (CAP_MAC_OVERRIDE, CAP_MAC_ADMIN) while a DAC LSM may require CAP_DAC_OVERRIDE. SELinux is likely to be the odd duck in this pond in that it does not use the capability mechanism in the way Nature intends it to be, opting to treat "privilege" with a completely different model. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 "", > > > but that can be separate and LSM specific without mucking up your basic > > > infrastructure applications. > > > > What would I do with such a thing? How would it get run? Spat out to > > where? > > Put it in /etc/init.d/cachefiles and run it at boot time. Put the > result into /etc/cachefiles.conf. Have cachefilesd read it and pass > it downward. More likely, run it at build time in your .spec file to generate cachefiles.conf, then run it again maybe upon a policy update or if the user selects a different policy. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 the use of it by the > > cachefilesd process. And then the security_task_kernel_act_as() hook > > just takes the secid as input rather than the task struct of the daemon, > > and applies it. At that point, nfsd can use the same mechanism for > > setting the acting SID based on the client process after doing its own > > authorization. > > I thought using secids was verboten as it made things too specific. Well, that has been Casey's objection in the past to it, but he seems to have accepted their use now for certain purposes, and they are already entrenched in the audit and labeled networking interfaces. > 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. It wouldn't perform any permission check, as the caller might a kernel-internal user that is just mapping back and forth like current users of security_secid_to_secctx, or it might be something that ultimately originated from userspace but the hook has no way of knowing why or what set of checks would be appropriate. You'd need a more specific hook for the authorization, one that would perform a permission check, e.g. an avc_has_perm() call. Which likely requires defining a new class and permissions for your cachefiles kernel interface. > Or is it that I need something that takes a secctx, converts it to a secid and > authorises its use all in one go? If it's this, why can't that be rolles into > security_task_kernel_act_as()? That sets up a task_security struct which is > then switched in and out without consultation of the LSM. I was under the impression that security_task_kernel_act_as() was being used to switch the current task to an acting context, not to initially set up a struct for later use. If you go with the latter approach, then what is the lifecycle on that struct? BTW, it gets a little confusing with your use of task_security for the full task security state vs our existing use of task_security_struct within SELinux for the task's LSM security blob. I suppose ours could be renamed to task_selinux. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 mucking up your basic > > infrastructure applications. > > What would I do with such a thing? How would it get run? Spat out to where? Put it in /etc/init.d/cachefiles and run it at boot time. Put the result into /etc/cachefiles.conf. Have cachefilesd read it and pass it downward. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 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 any conditional compilation or
> > linking,
> > > > but can build all the bits in to cachefilesd and have the appropriate
> > > > one
> > > > selected by the /etc/cachefilesd.conf.
> > > >
> > > > So, what do I invoke in libselinux, how do I configure it, and how do I
> > > > integrate the config into my RPM and install it?
> > > >
> > > > And then what does it give me that I can hand to the kernel (a context
> > string
> > > > for SELinux, I presume), how do I get the kernel to make a check on it,
> > how
> > > > do
> > > > I configure the check and how do I install that config from my RPM (I
> > presume
> > > > I just need to modify the .fc, .if and .te files that I have already)?
> > >
> > > That seems like an awful lot of work. I suggest that what you
> > > put in /etc/cachefilesd.conf is a line like:
> > >
> > >security_context:""
> > >
> > > and have your daemon pass "" into the kernel using
> > > a cachefile mechanism. The kernel code can call
> > > security_secctx_to_secid("") to determine if it's valid.
> > > No need to invoke LSM specific code in your daemon. 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.
> >
> > 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.
>
> 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 good enough to count on after all.
In Smack, I'd expect that you'd want to apply a CAP_MAC_OVERRIDE check.
In SELinux, we'd apply a permission check between the task's security
context and the specified security context so that we can control the
pairwise relationship between them via allow rules and constraints.
The kernel has no way of knowing whether the context was determined by
cachefileselinuxcontext or not; it only knows that some task is trying
to write some value to /cachefiles/context or whatever the kernel
interface is, and it needs to apply some authorization check there,
where that check is security-module-specific.
> > And then the security_task_kernel_act_as() hook
> > just takes the secid as input rather than the task struct of the daemon,
> > and applies it. At that point, nfsd can use the same mechanism for
> > setting the acting SID based on the client process after doing its own
> > authorization.
>
> good points all, in spite of my personal distaste for secids.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 good enough to count on after all. It can't be done in userspace, otherwise someone using the cachefilesd interface can pass an arbitrary context up. The security context has to be passed across the file descriptor attached to /dev/cachefiles along with the other configuration parameters as a text string. This fd selects the particular cache context that a particular instance of a running daemon is using. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 security_task_kernel_act_as() hook > just takes the secid as input rather than the task struct of the daemon, > and applies it. At that point, nfsd can use the same mechanism for > setting the acting SID based on the client process after doing its own > authorization. I thought using secids was verboten as it made things too specific. Have you example code for the security hook you mention? I'm not sure I understand why security_secctx_to_secid() is not sufficient. Or is it that I need something that takes a secctx, converts it to a secid and authorises its use all in one go? If it's this, why can't that be rolles into security_task_kernel_act_as()? That sets up a task_security struct which is then switched in and out without consultation of the LSM. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. What would I do with such a thing? How would it get run? Spat out to where? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 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 any conditional compilation or
> linking,
> > > but can build all the bits in to cachefilesd and have the appropriate one
> > > selected by the /etc/cachefilesd.conf.
> > >
> > > So, what do I invoke in libselinux, how do I configure it, and how do I
> > > integrate the config into my RPM and install it?
> > >
> > > And then what does it give me that I can hand to the kernel (a context
> string
> > > for SELinux, I presume), how do I get the kernel to make a check on it,
> how
> > > do
> > > I configure the check and how do I install that config from my RPM (I
> presume
> > > I just need to modify the .fc, .if and .te files that I have already)?
> >
> > That seems like an awful lot of work. I suggest that what you
> > put in /etc/cachefilesd.conf is a line like:
> >
> >security_context:""
> >
> > and have your daemon pass "" into the kernel using
> > a cachefile mechanism. The kernel code can call
> > security_secctx_to_secid("") to determine if it's valid.
> > No need to invoke LSM specific code in your daemon. 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.
>
> 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.
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 good enough to count on after all.
> And then the security_task_kernel_act_as() hook
> just takes the secid as input rather than the task struct of the daemon,
> and applies it. At that point, nfsd can use the same mechanism for
> setting the acting SID based on the client process after doing its own
> authorization.
good points all, in spite of my personal distaste for secids.
Casey Schaufler
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 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 any conditional compilation or
> > linking,
> > but can build all the bits in to cachefilesd and have the appropriate one
> > selected by the /etc/cachefilesd.conf.
> >
> > So, what do I invoke in libselinux, how do I configure it, and how do I
> > integrate the config into my RPM and install it?
> >
> > And then what does it give me that I can hand to the kernel (a context
> > string
> > for SELinux, I presume), how do I get the kernel to make a check on it, how
> > do
> > I configure the check and how do I install that config from my RPM (I
> > presume
> > I just need to modify the .fc, .if and .te files that I have already)?
>
> That seems like an awful lot of work. I suggest that what you
> put in /etc/cachefilesd.conf is a line like:
>
>security_context:""
>
> and have your daemon pass "" into the kernel using
> a cachefile mechanism. The kernel code can call
> security_secctx_to_secid("") to determine if it's valid.
> No need to invoke LSM specific code in your daemon. 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.
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 security_task_kernel_act_as() hook
just takes the secid as input rather than the task struct of the daemon,
and applies it. At that point, nfsd can use the same mechanism for
setting the acting SID based on the client process after doing its own
authorization.
> > > That mostly works, but it means that an update to policy may require an
> > > update to /etc/cachefilesd.conf, or that switching from one policy to
> > > another might likewise require changing that file. Versus using a
> > > separate policy-provided config file for the label.
> >
> > Whilst that's a fair point, if it's in a config file somewhere, then someone
> > may want to change it or someone may want to provide a second file for a
> > second cache with a different security label.
> >
> > > BTW, as should be obvious, some LSMs aren't label-based at all, so it
> > > would need to be optional.
> >
> > Aargh. In which case it might not be possible to make the SELinux context
> > passing from userspace -> kernel generic for all LSMs:-(
>
> For LSM's that don't use labels what you will have to pass in
> won't be a label, it will be something else. But since any LSM
> that wants to do networking or audit will have to deal with
> secid's and secctx's the method outlined above ought to fit the
> bill.
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 know very much about using > SELinux userspace stuff libraries or configuring them. > I don't have enough context anymore to help with design, but I can help with the actual usage of the libraries if you have specific questions. Karl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 configuring them. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 context > > > returned by a libselinux function. > > > > 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. > > > Is linking against libselinux is a viable option if it's not available under > > all LSM models? Is it available under all LSM models? Perhaps Casey can > > answer this one. > > Nope, they would all have their own libraries, if they have a library at > all. But that isn't your problem - your kernel interface should be > generic, and your LSM hooks should be generic, but your userspace isn't > required to be. Have a look at how many programs in the distribution > currently link against libselinux, whether directly or by dlopen'ing it. > > > > > I use to do that, but someone objected... Possibly Karl MacMillan. > > > > > > Yes, but I think I disagreed then too. > > > > So, who's right? > > Karl isn't a maintainer of the SELinux kernel code. And I had thought > that even he had reconsidered this idea after further discussion. > That's what I remember as well - I suggested the transition idea and then, after discussion, agreed that it wasn't the best approach. And, as Steve points out, it's not my call to make. Karl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 context returned by a libselinux function. 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. Is linking against libselinux is a viable option if it's not available under all LSM models? Is it available under all LSM models? Perhaps Casey can answer this one. Nope, they would all have their own libraries, if they have a library at all. But that isn't your problem - your kernel interface should be generic, and your LSM hooks should be generic, but your userspace isn't required to be. Have a look at how many programs in the distribution currently link against libselinux, whether directly or by dlopen'ing it. I use to do that, but someone objected... Possibly Karl MacMillan. Yes, but I think I disagreed then too. So, who's right? Karl isn't a maintainer of the SELinux kernel code. And I had thought that even he had reconsidered this idea after further discussion. That's what I remember as well - I suggested the transition idea and then, after discussion, agreed that it wasn't the best approach. And, as Steve points out, it's not my call to make. Karl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 configuring them. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 know very much about using SELinux userspace stuff libraries or configuring them. I don't have enough context anymore to help with design, but I can help with the actual usage of the libraries if you have specific questions. Karl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 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 any conditional compilation or linking, but can build all the bits in to cachefilesd and have the appropriate one selected by the /etc/cachefilesd.conf. So, what do I invoke in libselinux, how do I configure it, and how do I integrate the config into my RPM and install it? And then what does it give me that I can hand to the kernel (a context string for SELinux, I presume), how do I get the kernel to make a check on it, how do I configure the check and how do I install that config from my RPM (I presume I just need to modify the .fc, .if and .te files that I have already)? That seems like an awful lot of work. I suggest that what you put in /etc/cachefilesd.conf is a line like: security_context:whatever and have your daemon pass whatever into the kernel using a cachefile mechanism. The kernel code can call security_secctx_to_secid(whatever) to determine if it's valid. No need to invoke LSM specific code in your daemon. 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. 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 security_task_kernel_act_as() hook just takes the secid as input rather than the task struct of the daemon, and applies it. At that point, nfsd can use the same mechanism for setting the acting SID based on the client process after doing its own authorization. That mostly works, but it means that an update to policy may require an update to /etc/cachefilesd.conf, or that switching from one policy to another might likewise require changing that file. Versus using a separate policy-provided config file for the label. Whilst that's a fair point, if it's in a config file somewhere, then someone may want to change it or someone may want to provide a second file for a second cache with a different security label. BTW, as should be obvious, some LSMs aren't label-based at all, so it would need to be optional. Aargh. In which case it might not be possible to make the SELinux context passing from userspace - kernel generic for all LSMs:-( For LSM's that don't use labels what you will have to pass in won't be a label, it will be something else. But since any LSM that wants to do networking or audit will have to deal with secid's and secctx's the method outlined above ought to fit the bill. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 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 any conditional compilation or linking, but can build all the bits in to cachefilesd and have the appropriate one selected by the /etc/cachefilesd.conf. So, what do I invoke in libselinux, how do I configure it, and how do I integrate the config into my RPM and install it? And then what does it give me that I can hand to the kernel (a context string for SELinux, I presume), how do I get the kernel to make a check on it, how do I configure the check and how do I install that config from my RPM (I presume I just need to modify the .fc, .if and .te files that I have already)? That seems like an awful lot of work. I suggest that what you put in /etc/cachefilesd.conf is a line like: security_context:whatever and have your daemon pass whatever into the kernel using a cachefile mechanism. The kernel code can call security_secctx_to_secid(whatever) to determine if it's valid. No need to invoke LSM specific code in your daemon. 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. 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. 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 good enough to count on after all. And then the security_task_kernel_act_as() hook just takes the secid as input rather than the task struct of the daemon, and applies it. At that point, nfsd can use the same mechanism for setting the acting SID based on the client process after doing its own authorization. good points all, in spite of my personal distaste for secids. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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. What would I do with such a thing? How would it get run? Spat out to where? David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 security_task_kernel_act_as() hook just takes the secid as input rather than the task struct of the daemon, and applies it. At that point, nfsd can use the same mechanism for setting the acting SID based on the client process after doing its own authorization. I thought using secids was verboten as it made things too specific. Have you example code for the security hook you mention? I'm not sure I understand why security_secctx_to_secid() is not sufficient. Or is it that I need something that takes a secctx, converts it to a secid and authorises its use all in one go? If it's this, why can't that be rolles into security_task_kernel_act_as()? That sets up a task_security struct which is then switched in and out without consultation of the LSM. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 good enough to count on after all. It can't be done in userspace, otherwise someone using the cachefilesd interface can pass an arbitrary context up. The security context has to be passed across the file descriptor attached to /dev/cachefiles along with the other configuration parameters as a text string. This fd selects the particular cache context that a particular instance of a running daemon is using. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 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 any conditional compilation or linking, but can build all the bits in to cachefilesd and have the appropriate one selected by the /etc/cachefilesd.conf. So, what do I invoke in libselinux, how do I configure it, and how do I integrate the config into my RPM and install it? And then what does it give me that I can hand to the kernel (a context string for SELinux, I presume), how do I get the kernel to make a check on it, how do I configure the check and how do I install that config from my RPM (I presume I just need to modify the .fc, .if and .te files that I have already)? That seems like an awful lot of work. I suggest that what you put in /etc/cachefilesd.conf is a line like: security_context:whatever and have your daemon pass whatever into the kernel using a cachefile mechanism. The kernel code can call security_secctx_to_secid(whatever) to determine if it's valid. No need to invoke LSM specific code in your daemon. 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. 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. 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 good enough to count on after all. In Smack, I'd expect that you'd want to apply a CAP_MAC_OVERRIDE check. In SELinux, we'd apply a permission check between the task's security context and the specified security context so that we can control the pairwise relationship between them via allow rules and constraints. The kernel has no way of knowing whether the context was determined by cachefileselinuxcontext or not; it only knows that some task is trying to write some value to /cachefiles/context or whatever the kernel interface is, and it needs to apply some authorization check there, where that check is security-module-specific. And then the security_task_kernel_act_as() hook just takes the secid as input rather than the task struct of the daemon, and applies it. At that point, nfsd can use the same mechanism for setting the acting SID based on the client process after doing its own authorization. good points all, in spite of my personal distaste for secids. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 mucking up your basic infrastructure applications. What would I do with such a thing? How would it get run? Spat out to where? Put it in /etc/init.d/cachefiles and run it at boot time. Put the result into /etc/cachefiles.conf. Have cachefilesd read it and pass it downward. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
--- 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 applications for policy enforcement they need to be good enough to count on after all. It can't be done in userspace, otherwise someone using the cachefilesd interface can pass an arbitrary context up. Yes, but I would expect that interface to be protected (owned by root, mode 0400). If /dev/cachefiles has to be publicly accessable make it a privileged ioctl. The security context has to be passed across the file descriptor attached to /dev/cachefiles along with the other configuration parameters as a text string. I got that. 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. Casey Schaufler [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
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 the use of it by the cachefilesd process. And then the security_task_kernel_act_as() hook just takes the secid as input rather than the task struct of the daemon, and applies it. At that point, nfsd can use the same mechanism for setting the acting SID based on the client process after doing its own authorization. I thought using secids was verboten as it made things too specific. Well, that has been Casey's objection in the past to it, but he seems to have accepted their use now for certain purposes, and they are already entrenched in the audit and labeled networking interfaces. 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. It wouldn't perform any permission check, as the caller might a kernel-internal user that is just mapping back and forth like current users of security_secid_to_secctx, or it might be something that ultimately originated from userspace but the hook has no way of knowing why or what set of checks would be appropriate. You'd need a more specific hook for the authorization, one that would perform a permission check, e.g. an avc_has_perm() call. Which likely requires defining a new class and permissions for your cachefiles kernel interface. Or is it that I need something that takes a secctx, converts it to a secid and authorises its use all in one go? If it's this, why can't that be rolles into security_task_kernel_act_as()? That sets up a task_security struct which is then switched in and out without consultation of the LSM. I was under the impression that security_task_kernel_act_as() was being used to switch the current task to an acting context, not to initially set up a struct for later use. If you go with the latter approach, then what is the lifecycle on that struct? BTW, it gets a little confusing with your use of task_security for the full task security state vs our existing use of task_security_struct within SELinux for the task's LSM security blob. I suppose ours could be renamed to task_selinux. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
