Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/15/2015 8:55 AM, Stephen Smalley wrote:
> On 12/15/2015 11:06 AM, Casey Schaufler wrote:
>> On 12/15/2015 7:00 AM, Stephen Smalley wrote:
>>> On 12/14/2015 05:57 PM, Roberts, William C wrote:
>>>> 
>>>>>>
>>>>>> If I understand correctly, the goal here is to avoid the lookup from
>>>>>> pid to context. If we somehow Had the context or a token to a context
>>>>>> during the ipc transaction to userspace, we could just use that In
>>>>>> computing the access decision. If that is correct, then since we have
>>>>>> PID, why not just extend the SE Linux compute av decision interface to 
>>>>>> support
>>>>> passing of PID and then it can do the lookup in the Kernel?
>>>>>
>>>>> That's no less racy than getpidcon().
>>>>>
>>>>
>>>> I got a bounce from when I sent this from gmail, resending.
>>>>
>>>> True, but in this case the binder transaction would be dead...
>>>>
>>>> Why not just pass ctx? It's less than ideal, but it might be good enough 
>>>> for now until contexts get unwieldy big.
>>>>
>>>> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk 
>>>> ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
>>>> END { printf("average: %dn", totlen/NR); } '
>>>>
>>>> The avg type length for domain types in external/sepolicy is 7. Add the 
>>>> full ctx:
>>>>
>>>> u:r:xxx:s0(cat)
>>>>
>>>> 1. We're looking at like 18 or so bytes, how do we know this won't be 
>>>> "fast enough"?
>>>> 2. What's the current perf numbers, and what's agreed upon on what you 
>>>> need to hit to be fast enough?
>>>> 3. I'm assuming the use case is in service manager, but would a userspace 
>>>> cache of AVD's help? Then you can (possibly) avoid both kernel trips, and 
>>>> you can invalidate the cache on policy reload and on PID deaths? In the 
>>>> case of service manager would it always be a miss based on usage pattern? 
>>>> I'm assuming things would say hey resolve this once, and be done. However, 
>>>> you could only do the ctx lookup and do the avd based on the policy in 
>>>> user space, thus avoiding 1 of two trips.
>>>
>>> 1. I don't think it is the size of the context that is the concern but 
>>> rather the fact that it is a variable-length string, whereas current binder 
>>> commands use fixed-size arguments and encode the size in the command value 
>>> (common for ioctls).  Supporting passing a variable-length string would be 
>>> a change to the protocol and would complicate the code.  On the performance 
>>> side, it means generating a context string from the secid and then copying 
>>> it to userspace on each IPC (versus just getting the secid and putting that 
>>> in the existing binder_transaction_data that is already copied to 
>>> userspace).
>>
>> I have long wondered why SELinux generates the context string
>> of the secid more than once. Audit performance alone would
>> justify keeping it around. The variable length issue isn't
>> so difficult as you make it out. As William pointed out earlier,
>> most SELinux contexts are short. Two protocols, one with a
>> fixed length of 16 chars (typical is 7) and one with a fixed
>> length of 256 (for abnormal contexts) solve the problem without
>> complicating the code hardly at all.
>>
>> If it's such a problem, why do we have SO_PEERSEC return a
>> variable length string? That's been around forever and seems
>> to work just fine.
>
> Generating an audit record means you are already on the slow path, so adding 
> the cost of generating a context at that point shouldn't be significant (but 
> if one has performance data to the contrary, that would always be of 
> interest). Keeping complete context strings in kernel memory at all times 
> wasn't viewed as desirable, particularly when you consider the next point.

Making a slow path slower doesn't seem like a great idea to me.
The performance of audit is a major impediment to its use. There
are some cases where I can see regenerating the context on demand
as an optimization, but never in a case where the system regularly
exports them.

>
> There is no internal limit on SELinux context size and one can in fact 
> generate a SELinux context string that exceeds 256 bytes (just create a 
> categor

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/14/2015 9:03 AM, Mike Palmiotto wrote:
> On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore <p...@paul-moore.com> wrote:
>> On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote:
>>> Perhaps we could provide a new fixed-size tokenized version of the
>>> security context string for export to userspace that could be embedded
>>> in the binder transaction structure?  This could avoid both the
>>> limitations of the current secid (e.g. limited to 32 bits, no
>>> stackability) and the overhead of copying context strings on every IPC.
>> On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote:
>>> How about this: Provide an alias mechanism for secctx. There would then
>>> be a secid (32bits) a secctx (arbitrary text string) and a secalias which
>>> could be a limited string of some length. You could use the alias in place
>>> of the secctx anywhere you liked.
>> My initial reaction to the secalias idea isn't overly positive.  It seems 
>> like
>> a kludge with a lot of duplication, both in terms of code and concept, and a
>> lot of risk for confusion both by users and policy writers.  I think if we
>> really wanted to limit the security label string format to a small size we
>> should have done that from the start, it's too late now.
>>
>> Assuming we see some binder performance numbers, and the numbers are bad, I'm
>> a little more open to doing something with the secid token.  Up to this point
>> we haven't made any guarantees about the token and we haven't exported it
>> outside the kernel so there is some ability to change it to fit our needs.
>> Granted, this isn't perfect solution either, and perhaps ultimately we would
>> need something else, but I think it is worth looking into this first before 
>> we
>> introduce another string label.
> Agreed here. I can definitely see a use for security identifier tokens
> in SE Postgres as well. Ideally these tokens would be 32 bit uints as
> opposed to shorter string aliases.

If you need something persistent you can't use what the
kernel would provide, and if you don't you can make it up
on the fly. The binder case is different (and evil) because
the binder driver is letting user space make decisions on
behalf of the kernel.

>
> --Mike
>
>> --
>> paul moore
>> www.paul-moore.com
>>
>> ___
>> Selinux mailing list
>> seli...@tycho.nsa.gov
>> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>> To get help, send an email containing "help" to 
>> selinux-requ...@tycho.nsa.gov.

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/11/2015 2:14 PM, Stephen Smalley wrote:
> On 12/11/2015 02:55 PM, Paul Moore wrote:
>> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman  wrote:
>>> Hello,
>>>
>>> I would like to write a patch that would expose, via selinuxfs, the
>>> mapping between secids in the kernel and security contexts to
>>> user-space, but before doing so wanted to get some feedback as to
>>> whether or not such an endeavor could have any support upstream.  The
>>> direct motivation for this is the desire to communicate calling security
>>> ids/contexts over binder IPC on android for use in a user-space object
>>> manager.  Passing the security ids themselves would be simpler and more
>>> efficient in the critical kernel path, but they currently have no
>>> user-space meaning.
>>
>> In general we try to avoid exposing the secid tokens outside the
>> kernel, I view them as an implementation hack designed to make it
>> easier to manage and operate on the security labels in the kernel.  I
>> suspect you will hear something very similar from Casey and the other
>> Smack developers.  Another consideration is the long standing LSM
>> stacking effort, they have several good reasons for wanting to abolish
>> the secid token, propagating it to userspace would make that all but
>> impossible.
>>
>> While I'm sympathetic to your desire for less complexity and better
>> performance in passing security labels, from a kernel perspective I
>> think we lose too much in exporting the secid tokens outside the LSM.
>
> To clarify, security identifiers were by design provided in the Flask 
> architecture and SELinux as lightweight, non-persistent handles to security 
> contexts, and exposed to userspace by the original SELinux API (pre-2.6, of 
> course).  They were only removed when we transitioned to using extended 
> attributes and the xattr API for file security labels, and we made all of the 
> other APIs consistent as passing context strings seemed acceptable for proc 
> and selinuxfs as well.  There was some thought to turning SIDs into proper 
> reference-counted objects or even wrapping them with descriptors so that 
> their lifecycles could be fully managed by the kernel, but that never 
> happened.
>
> Passing a security context string on every binder IPC may be too costly from 
> a performance point of view (numbers would be helpful here).  I think this 
> situation differs from that of stream sockets (i.e. getsockopt SO_PEERSEC), 
> since they are looking at enabling passing of sender security label for every 
> binder IPC (not just specific applications) and since binder IPC is quite 
> different from stream socket IPC in its semantics and its performance.

It seems to me that a better approach might be for the object manager
to tell the binder driver about its security constraints and have the
binder driver do the check in the kernel. I realize that could require
additional LSM hooks (just like kdbus) but I think you may be looking
at that anyway, unless you're convinced binder will only ever work with
SELinux.

>
> Perhaps we could provide a new fixed-size tokenized version of the security 
> context string for export to userspace that could be embedded in the binder 
> transaction structure?  This could avoid both the limitations of the current 
> secid (e.g. limited to 32 bits, no stackability) and the overhead of copying 
> context strings on every IPC.

How about this: Provide an alias mechanism for secctx. There would then
be a secid (32bits) a secctx (arbitrary text string) and a secalias which
could be a limited string of some length. You could use the alias in place
of the secctx anywhere you liked. You would always use the secalais in
binder communications. The advantage is that the kernel would know that
"#fish" was an alias for "Raygun_t:s27", just like the object manager.
The other, longer term, advantage is that when (if?) we get to extreme
module stacking we'll have a mechanism for dealing with a secctx like

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/11/2015 10:37 AM, Daniel Cashman wrote:
> Hello,
>
> I would like to write a patch that would expose, via selinuxfs, the
> mapping between secids in the kernel and security contexts to
> user-space, but before doing so wanted to get some feedback as to
> whether or not such an endeavor could have any support upstream.

Please abandon this.

> The
> direct motivation for this is the desire to communicate calling security
> ids/contexts over binder IPC on android for use in a user-space object
> manager.  Passing the security ids themselves would be simpler and more
> efficient in the critical kernel path, but they currently have no
> user-space meaning.

The security module infrastructure makes no guarantees about
secids. A security module is not required to maintain a persistent
relationship between the secid and a particular secctx. SELinux
does maintain a persistent relationship, but I don't believe that
there is any desire to commit to everything associated with exposing
that.

Binder ought to have access to more than the secid of the processes
and objects involved. Look into the possibilities there before you
take this approach.

>
> Thank You,
> Dan
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH] VFS: Remove security module inode blob allocation overhead - unmundged

[Casey Schaufler]

Subject: [RFC PATCH] VFS: Remove security module inode blob allocation overhead

Apologies for the previous mundged posting.

The LSM infrastructure requires that the security modules
allocate and free inode data as they require it. SELinux
and Smack, the two security modules that use inode data,
require that all inodes allocate security data. Allocating
and freeing this data independently from the inode adds
unnecessary overhead. The indirection from the inode to
the security blob also adds overhead.

I fully expect objections to this approach. This approach
would have been unreasonable when the LSM was introduced,
as the majority of systems did not use a security module.
That is no longer the case. Most systems (RedHat, Fedora,
Ubuntu, Tizen, Android) use security modules today.

Putting the security blob directly into the inode increases
the size of the inode. The relative sizes are:

Security disabled:  552
Security enabled, no module:552
Security enabled with Smack:624
Security enabled with SELinux:  632
Security enabled with both: 632

The first two numbers are the same because the module
data is only included if the module is included. There
is no i_security taking up space when it isn't needed.
The last two numbers are the same because i_selinux
and i_smack are unioned, which is sane since you can't
use them both at the same time. Systems using only
AppArmor get smaller inodes when properly configured.
Systems with security modules compiled out are unaffected.
Systems using either SELinux or Smack get full advantage.

It should be clear that for a properly configured kernel
it will always be advantageous to include the security blob
in the inode. By "properly configured" I mean simply that
the only security facilities built in are the ones that are
intended to be used, or that the value of generality is
sufficient to incur some overhead. A downside of this
approach is that the security blob structures are exposed.
I expect that there is some compiler trick I could use to
get the size of the blobs without doing so, but I am
disinclined to pursue that. Exposing the blob structure
has typing advantages.

Earlier discussions about changing the inode structure to
better accommodate the use of security data include:

https://lkml.org/lkml/2013/6/3/516

Signed-off-by: Casey Schaufler <ca...@schaufler-ca.com>
---
 fs/nfs/inode.c|   5 +-
 include/linux/fs.h|  11 +++-
 include/linux/selinux_blob.h  |  41 
 include/linux/smack_blob.h|  32 +
 security/security.c   |   2 +-
 security/selinux/hooks.c  | 132 +-
 security/selinux/include/objsec.h |  14 +---
 security/selinux/selinuxfs.c  |   8 +--
 security/smack/smack.h|  16 +
 security/smack/smack_lsm.c|  54 ++--
 10 files changed, 174 insertions(+), 141 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 326d9e1..157f99e 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -292,11 +292,14 @@ void nfs_setsecurity(struct inode *inode, struct 
nfs_fattr *fattr,
struct nfs4_label *label)
 {
int error;
+   u32 secid = 0;
 
if (label == NULL)
return;
 
-   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && 
inode->i_security) {
+   security_inode_getsecid(inode, );
+
+   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && secid != 0) {
error = security_inode_notifysecctx(inode, label->label,
label->len);
if (error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..65d17fb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -598,8 +600,15 @@ struct inode {
struct address_space*i_mapping;
 
 #ifdef CONFIG_SECURITY
-   void*i_security;
+   union {
+#ifdef CONFIG_SECURITY_SELINUX
+   struct inode_selinuxi_selinux;
+#endif
+#ifdef CONFIG_SECURITY_SMACK
+   struct inode_smack  i_smack;
 #endif
+   };
+#endif /* CONFIG_SECURITY */
 
/* Stat data, not accessed from path walking */
unsigned long   i_ino;
diff --git a/include/linux/selinux_blob.h b/include/linux/selinux_blob.h
new file mode 100644
index 000..0ee65bc
--- /dev/null
+++ b/include/linux/selinux_blob.h
@@ -0,0 +1,41 @@
+/*
+ *  NSA Security-Enhanced Linux (SELinux) security module
+ *
+ *  This file contains the SELinux security data structures for kernel objects
+ *  that are exposed outside the module.
+ *
+ *  Author(s):  Stephen Smalley, <s...@epoch.ncsc.mil>
+ * Chris Vance, <cva...@nai.com>
+ *

[RFC PATCH] VFS: Remove security module inode blob allocation overhead

[Casey Schaufler]

Subject: [RFC PATCH] VFS: Remove security module inode blob allocation overhead

The LSM infrastructure requires that the security modules
allocate and free inode data as they require it. SELinux
and Smack, the two security modules that use inode data,
require that all inodes allocate security data. Allocating
and freeing this data independently from the inode adds
unnecessary overhead. The indirection from the inode to
the security blob also adds overhead.

I fully expect objections to this approach. This approach
would have been unreasonable when the LSM was introduced,
as the majority of systems did not use a security module.
That is no longer the case. Most systems (RedHat, Fedora,
Ubuntu, Tizen, Android) use security modules today.

Putting the security blob directly into the inode increases
the size of the inode. The relative sizes are:

Security disabled:  552
Security enabled, no module:552
Security enabled with Smack:624
Security enabled with SELinux:  632
Security enabled with both: 632

The first two numbers are the same because the module
data is only included if the module is included. There
is no i_security taking up space when it isn't needed.
The last two numbers are the same because i_selinux
and i_smack are unioned, which is sane since you can't
use them both at the same time. Systems using only
AppArmor get smaller inodes when properly configured.
Systems with security modules compiled out are unaffected.
Systems using either SELinux or Smack get full advantage.

It should be clear that for a properly configured kernel
it will always be advantageous to include the security blob
in the inode. By "properly configured" I mean simply that
the only security facilities built in are the ones that are
intended to be used, or that the value of generality is
sufficient to incur some overhead. A downside of this
approach is that the security blob structures are exposed.
I expect that there is some compiler trick I could use to
get the size of the blobs without doing so, but I am
disinclined to pursue that. Exposing the blob structure
has typing advantages.

Earlier discussions about changing the inode structure to
better accommodate the use of security data include:

https://lkml.org/lkml/2013/6/3/516

Signed-off-by: Casey Schaufler <ca...@schaufler-ca.com>
---
 fs/nfs/inode.c|   5 +-
 include/linux/fs.h|  11 +++-
 include/linux/selinux_blob.h  |  41 
 include/linux/smack_blob.h|  32 +
 security/security.c   |   2 +-
 security/selinux/hooks.c  | 132 +-
 security/selinux/include/objsec.h |  14 +---
 security/selinux/selinuxfs.c  |   8 +--
 security/smack/smack.h|  16 +
 security/smack/smack_lsm.c|  54 ++--
 10 files changed, 174 insertions(+), 141 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 326d9e1..157f99e 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -292,11 +292,14 @@ void nfs_setsecurity(struct inode *inode, struct 
nfs_fattr *fattr,
struct nfs4_label *label)
 {
int error;
+   u32 secid = 0;
 
 	if (label == NULL)

return;
 
-	if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && inode->i_security) {

+   security_inode_getsecid(inode, );
+
+   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && secid != 0) {
error = security_inode_notifysecctx(inode, label->label,
label->len);
if (error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..65d17fb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 

 #include 
@@ -598,8 +600,15 @@ struct inode {
struct address_space*i_mapping;
 
 #ifdef CONFIG_SECURITY

-   void*i_security;
+   union {
+#ifdef CONFIG_SECURITY_SELINUX
+   struct inode_selinuxi_selinux;
+#endif
+#ifdef CONFIG_SECURITY_SMACK
+   struct inode_smack  i_smack;
 #endif
+   };
+#endif /* CONFIG_SECURITY */
 
 	/* Stat data, not accessed from path walking */

unsigned long   i_ino;
diff --git a/include/linux/selinux_blob.h b/include/linux/selinux_blob.h
new file mode 100644
index 000..0ee65bc
--- /dev/null
+++ b/include/linux/selinux_blob.h
@@ -0,0 +1,41 @@
+/*
+ *  NSA Security-Enhanced Linux (SELinux) security module
+ *
+ *  This file contains the SELinux security data structures for kernel objects
+ *  that are exposed outside the module.
+ *
+ *  Author(s):  Stephen Smalley, <s...@epoch.ncsc.mil>
+ * Chris Vance, <cva...@nai.com>
+ * Wayne Salamon, <wsala...@nai.com>
+ * 

[PATCH] Smack: File receive for sockets

[Casey Schaufler]

Subject: [PATCH] Smack: File receive for sockets

The existing file receive hook checks for access on
the file inode even for UDS. This is not right, as
the inode is not used by Smack to make access checks
for sockets. This change checks for an appropriate
access relationship between the receiving (current)
process and the socket. If the process can't write
to the socket's send label or the socket's receive
label can't write to the process fail.

This will allow the legitimate cases, where the
socket sender and socket receiver can freely communicate.
Only strangly set socket labels should cause a problem.

Signed-off-by: Casey Schaufler <ca...@schaufler-ca.com>
---
 security/smack/smack_lsm.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index ff81026..b20ef06 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1860,12 +1860,34 @@ static int smack_file_receive(struct file *file)
int may = 0;
struct smk_audit_info ad;
struct inode *inode = file_inode(file);
+   struct socket *sock;
+   struct task_smack *tsp;
+   struct socket_smack *ssp;
 
 	if (unlikely(IS_PRIVATE(inode)))

return 0;
 
 	smk_ad_init(, __func__, LSM_AUDIT_DATA_PATH);

smk_ad_setfield_u_fs_path(, file->f_path);
+
+   if (S_ISSOCK(inode->i_mode)) {
+   sock = SOCKET_I(inode);
+   ssp = sock->sk->sk_security;
+   tsp = current_security();
+   /*
+* If the receiving process can't write to the
+* passed socket or if the passed socket can't
+* write to the receiving process don't accept
+* the passed socket.
+*/
+   rc = smk_access(tsp->smk_task, ssp->smk_out, MAY_WRITE, );
+   rc = smk_bu_file(file, may, rc);
+   if (rc < 0)
+   return rc;
+   rc = smk_access(ssp->smk_in, tsp->smk_task, MAY_WRITE, );
+   rc = smk_bu_file(file, may, rc);
+   return rc;
+   }
/*
 * This code relies on bitmasks.
 */

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] Smack: harmless underflow in smk_set_cipso()

[Casey Schaufler]

On 11/3/2015 2:15 PM, Dan Carpenter wrote:

This causes a static checker warning because "maplevel" is set by the
user and we cap the upper bound but not the lower bound.  It seems
harmless to me and it's root only but we may as well make the static
checker happy.

Also checkpatch complains that we should use kstrtouint() instead of
sscanf here.

Signed-off-by: Dan Carpenter 


This no longer parses cipso specifications correctly.
I haven't investigated why. It looks as if it should
work. Does kstrtouint() allow for leading whitespace?
If not, that's the problem.
 



diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index 94bd9e4..ebb1241 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -862,7 +862,7 @@ static ssize_t smk_set_cipso(struct file *file, const char 
__user *buf,
struct smack_known *skp;
struct netlbl_lsm_secattr ncats;
char mapcatset[SMK_CIPSOLEN];
-   int maplevel;
+   unsigned int maplevel;
unsigned int cat;
int catlen;
ssize_t rc = -EINVAL;
@@ -912,8 +912,8 @@ static ssize_t smk_set_cipso(struct file *file, const char 
__user *buf,
else
rule += strlen(skp->smk_known) + 1;
  
-	ret = sscanf(rule, "%d", );

-   if (ret != 1 || maplevel > SMACK_CIPSO_MAXLEVEL)
+   ret = kstrtouint(rule, 10, );
+   if (ret || maplevel > SMACK_CIPSO_MAXLEVEL)
goto out;
  
  	rule += SMK_DIGITLEN;




--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Security next tree synced to v4.4-rc2

[Casey Schaufler]

Thank you. This is very helpful.

On 11/23/2015 3:47 AM, James Morris wrote:

For LSM developers who might be waiting for a resync to Linus...





--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 02/11] lsm: /proc/$PID/attr/label_map file and getprocattr_seq hook

[Casey Schaufler]

On 10/14/2015 5:41 AM, Lukasz Pawelczyk wrote:
> This commit adds a new proc attribute, label_map that is required by an
> upcoming Smack namespace. In general it can be used to hold a map of
> labels, e.g. to be used in namespaces.
>
> Due to the nature of this file, the standard getprocattr hook might not
> be enough to handle it. The map's output can in principle be greater
> than page size to which the aforementioned hook is limited.
> To handle this properly a getprocattr_seq LSM hook has been added that
> makes it possible to handle any chosen proc attr by seq operations.
>
> See the documentation in the patch below for the details about how to
> use the hook.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Acked-by: Serge Hallyn <serge.hal...@canonical.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>



> ---
>  fs/proc/base.c| 81 
> +++
>  include/linux/lsm_hooks.h | 15 +
>  include/linux/security.h  |  9 ++
>  security/security.c   |  8 +
>  4 files changed, 107 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b25eee4..9ec88b8 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2327,20 +2327,77 @@ out:
>  }
>  
>  #ifdef CONFIG_SECURITY
> +static int proc_pid_attr_open(struct inode *inode, struct file *file)
> +{
> + const char *name = file->f_path.dentry->d_name.name;
> + const struct seq_operations *ops;
> + struct task_struct *task;
> + struct seq_file *seq;
> + int ret;
> +
> + file->private_data = NULL;
> +
> + task = get_proc_task(inode);
> + if (!task)
> + return -ESRCH;
> +
> + /* don't use seq_ops if they are not provided by LSM */
> + ret = security_getprocattr_seq(task, name, );
> + if (ret == -EOPNOTSUPP) {
> + ret = 0;
> + goto put_task;
> + }
> + if (ret)
> + goto put_task;
> +
> + ret = seq_open(file, ops);
> + if (ret)
> + goto put_task;
> +
> + seq = file->private_data;
> + seq->private = task;
> +
> + return 0;
> +
> +put_task:
> + put_task_struct(task);
> + return ret;
> +}
> +
> +static int proc_pid_attr_release(struct inode *inode, struct file *file)
> +{
> + struct seq_file *seq;
> + struct task_struct *task;
> +
> + /* don't use seq_ops if they were not provided by LSM */
> + if (file->private_data == NULL)
> + return 0;
> +
> + seq = file->private_data;
> + task = seq->private;
> + put_task_struct(task);
> +
> + return seq_release(inode, file);
> +}
> +
>  static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
> size_t count, loff_t *ppos)
>  {
> - struct inode * inode = file_inode(file);
> + struct inode *inode = file_inode(file);
> + const char *name = file->f_path.dentry->d_name.name;
>   char *p = NULL;
>   ssize_t length;
> - struct task_struct *task = get_proc_task(inode);
> + struct task_struct *task;
>  
> + /* use seq_ops if they were provided by LSM */
> + if (file->private_data)
> + return seq_read(file, buf, count, ppos);
> +
> + task = get_proc_task(inode);
>   if (!task)
>   return -ESRCH;
>  
> - length = security_getprocattr(task,
> -   (char*)file->f_path.dentry->d_name.name,
> -   );
> + length = security_getprocattr(task, (char *)name, );
>   put_task_struct(task);
>   if (length > 0)
>   length = simple_read_from_buffer(buf, count, ppos, p, length);
> @@ -2348,6 +2405,15 @@ static ssize_t proc_pid_attr_read(struct file * file, 
> char __user * buf,
>   return length;
>  }
>  
> +static loff_t proc_pid_attr_lseek(struct file *file, loff_t offset, int 
> whence)
> +{
> + /* use seq_ops if they were provided by LSM */
> + if (file->private_data)
> + return seq_lseek(file, offset, whence);
> +
> + return generic_file_llseek(file, offset, whence);
> +}
> +
>  static ssize_t proc_pid_attr_write(struct file * file, const char __user * 
> buf,
>  size_t count, loff_t *ppos)
>  {
> @@ -2394,9 +2460,11 @@ out_no_task:
>  }
>  
>  static const struct file_operations proc_pid_attr_operations = {
> + .open   = proc_pid_attr_open,
> + .release= proc_pid_attr_release,
>   .read 

Re: [PATCH v4 10/11] smack: namespace implementation

[Casey Schaufler]

On 10/14/2015 5:42 AM, Lukasz Pawelczyk wrote:
> This commit uses all the changes introduced in "namespace groundwork"
> and previous preparation patches and makes smack aware of its namespace
> and mapped labels.
>
> It modifies the following functions to be namespace aware:
> - smk_access
> - smk_find_label_name
> - smk_get_label
>
> And all functions that use them (e.g. smk_tskacc).
>
> It also adds another function that is used throughout Smack LSM hooks:
> - smk_labels_valid - it checks whether both, subject and object labels
>   are properly mapped in a namespace where they are to be used. This
>   function is used mostly together with a capability check when there is
>   no proper access check that usually checks for that.
>
> All the Smack LSM hooks have been adapted to be namespace aware.
>
> The capabilities (CAP_MAC_ADMIN, CAP_MAC_OVERRIDE) has been allowed in
> the namespace for few cases. Check the documentation for the details.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Reviewed-by: Casey Schaufler <ca...@schaufler-ca.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  security/smack/smack.h|  29 +++-
>  security/smack/smack_access.c | 109 ++--
>  security/smack/smack_lsm.c| 390 
> ++
>  security/smack/smack_ns.c |  39 +
>  security/smack/smackfs.c  |  63 ---
>  5 files changed, 483 insertions(+), 147 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 4b7489f..3d432f4 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -119,6 +119,7 @@ struct superblock_smack {
>   struct smack_known  *smk_floor;
>   struct smack_known  *smk_hat;
>   struct smack_known  *smk_default;
> + struct user_namespace   *smk_ns;
>   int smk_initialized;
>  };
>  
> @@ -126,6 +127,7 @@ struct socket_smack {
>   struct smack_known  *smk_out;   /* outbound label */
>   struct smack_known  *smk_in;/* inbound label */
>   struct smack_known  *smk_packet;/* TCP peer label */
> + struct user_namespace   *smk_ns;/* user namespace */
>  };
>  
>  /*
> @@ -146,6 +148,14 @@ struct task_smack {
>   struct mutexsmk_rules_lock; /* lock for the rules */
>  };
>  
> +/*
> + * Used for IPC objects (sem, shm, etc)
> + */
> +struct ipc_smack {
> + struct smack_known  *smk_known; /* label for access control */
> + struct user_namespace   *smk_ns;/* user namespace */
> +};
> +
>  #define  SMK_INODE_INSTANT   0x01/* inode is instantiated */
>  #define  SMK_INODE_TRANSMUTE 0x02/* directory is transmuting */
>  #define  SMK_INODE_CHANGED   0x04/* smack was transmuted */
> @@ -319,10 +329,11 @@ struct smk_audit_info {
>   */
>  int smk_access_entry(char *, char *, struct list_head *);
>  int smk_access(struct smack_known *, struct smack_known *,
> -int, struct smk_audit_info *);
> +struct user_namespace *, int, struct smk_audit_info *);
>  int smk_tskacc(struct task_struct *, struct smack_known *,
> +struct user_namespace *, u32, struct smk_audit_info *);
> +int smk_curacc(struct smack_known *, struct user_namespace *,
>  u32, struct smk_audit_info *);
> -int smk_curacc(struct smack_known *, u32, struct smk_audit_info *);
>  struct smack_known *smack_from_secid(const u32);
>  char *smk_parse_smack(const char *string, int len, bool *allocated);
>  int smk_netlbl_mls(int, char *, struct netlbl_lsm_secattr *, int);
> @@ -335,8 +346,9 @@ int smack_has_ns_privilege(struct task_struct *task,
>  int smack_has_privilege(struct task_struct *task, int cap);
>  int smack_ns_privileged(struct user_namespace *user_ns, int cap);
>  int smack_privileged(int cap);
> -char *smk_find_label_name(struct smack_known *skp);
> -struct smack_known *smk_get_label(const char *string, int len, bool import);
> +char *smk_find_label_name(struct smack_known *skp, struct user_namespace 
> *ns);
> +struct smack_known *smk_get_label(const char *string, int len, bool import,
> +   struct user_namespace *ns);
>  
>  /*
>   * These functions are in smack_ns.c
> @@ -350,6 +362,15 @@ struct smack_known *smk_find_unmapped(const char 
> *string, int len,
>  extern const struct seq_operations proc_label_map_seq_operations;
>  ssize_t proc_label_map_write(struct task_struct *p, const struct cred 
> *f_cred,
>void *value, size_t size);
> +bool smk_labels_valid(struct smack_known *sbj, struct smack_known *obj,
&

Re: [PATCH v4 09/11] smack: namespace groundwork

[Casey Schaufler]

On 10/14/2015 5:42 AM, Lukasz Pawelczyk wrote:
> This commit introduces several changes to Smack to prepare it for
> namespace implementation. All the changes are related to namespaces.
>
> Overview of the changes:
> - Adds required data structures for mapped labels and functions to
>   operate on them.
> - Implements the proc interface /proc/$PID/attr/label_map that can be
>   used for remapping of labels for a specific namespace. Also for
>   checking the map.
> - Modifies handling of special built-in labels. Detects them on import
>   and assigns the same char* pointer regardless whether it's used in a
>   normal or a mapped label. This way we can always compare them by ==
>   instead of strcmp().
> - Adds User namespace hooks implementation
>
> This patch introduces both internal and user-space visible APIs to
> handle namespaced labels and Smack namespaces but the behaviour of Smack
> should not be changed. The APIs are there, but they have no impact yet.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Reviewed-by: Casey Schaufler <ca...@schaufler-ca.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  security/smack/Kconfig|  10 ++
>  security/smack/Makefile   |   1 +
>  security/smack/smack.h|  45 -
>  security/smack/smack_access.c |  47 -
>  security/smack/smack_lsm.c| 134 +-
>  security/smack/smack_ns.c | 404 
> ++
>  6 files changed, 626 insertions(+), 15 deletions(-)
>  create mode 100644 security/smack/smack_ns.c
>
> diff --git a/security/smack/Kconfig b/security/smack/Kconfig
> index 271adae..b19a7fb 100644
> --- a/security/smack/Kconfig
> +++ b/security/smack/Kconfig
> @@ -40,3 +40,13 @@ config SECURITY_SMACK_NETFILTER
> This enables security marking of network packets using
> Smack labels.
> If you are unsure how to answer this question, answer N.
> +
> +config SECURITY_SMACK_NS
> + bool "Smack namespace"
> + depends on SECURITY_SMACK
> + depends on USER_NS
> + help
> +   This enables Smack namespace that makes it possible to map
> +   specific labels within user namespace (analogously to mapping
> +   UIDs) and to gain MAC capabilities over them.
> +   If you are unsure how to answer this question, answer N.
> diff --git a/security/smack/Makefile b/security/smack/Makefile
> index ee2ebd5..5faebd7 100644
> --- a/security/smack/Makefile
> +++ b/security/smack/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_SECURITY_SMACK) := smack.o
>  
>  smack-y := smack_lsm.o smack_access.o smackfs.o
>  smack-$(CONFIG_SECURITY_SMACK_NETFILTER) += smack_netfilter.o
> +smack-$(CONFIG_SECURITY_SMACK_NS) += smack_ns.o
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 98bb676..4b7489f 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Use IPv6 port labeling if IPv6 is enabled and secmarks
> @@ -74,8 +75,36 @@ struct smack_known {
>   struct netlbl_lsm_secattr   smk_netlabel;   /* on wire labels */
>   struct list_headsmk_rules;  /* access rules */
>   struct mutexsmk_rules_lock; /* lock for rules */
> +#ifdef CONFIG_SECURITY_SMACK_NS
> + struct list_headsmk_mapped; /* namespaced labels */
> + struct mutexsmk_mapped_lock;
> +#endif /* CONFIG_SECURITY_SMACK_NS */
>  };
>  
> +#ifdef CONFIG_SECURITY_SMACK_NS
> +
> +/*
> + * User namespace security pointer content.
> + */
> +struct smack_ns {
> + struct list_headsmk_mapped; /* namespaced labels */
> + struct mutexsmk_mapped_lock;
> +};
> +
> +/*
> + * A single entry for a namespaced/mapped label.
> + */
> +struct smack_known_ns {
> + struct list_headsmk_list_known;
> + struct list_headsmk_list_ns;
> + struct user_namespace   *smk_ns;
> + char*smk_mapped;
> + struct smack_known  *smk_unmapped;
> + boolsmk_allocated;
> +};
> +
> +#endif /* CONFIG_SECURITY_SMACK_NS */
> +
>  /*
>   * Maximum number of bytes for the levels in a CIPSO IP option.
>   * Why 23? CIPSO is constrained to 30, so a 32 byte buffer is
> @@ -295,7 +324,7 @@ int smk_tskacc(struct task_struct *, struct smack_known *,
>  u32, struct smk_audit_info *);
>  int smk_curacc(struct smack_known *, u32, struct smk_audit_info *);
>  struct smack_known *smack_from_secid(const u32);
> -char *smk_parse_smack(

Re: [PATCH v4 08/11] smack: misc cleanups in preparation for a namespace patch

[Casey Schaufler]

On 10/14/2015 5:42 AM, Lukasz Pawelczyk wrote:
> This patch does some small miscellaneous cleanups and additions that
> should not change the code behaviour in any way. Its only purpose is to
> shape the code in a way that the smack namespace patches would be
> smaller and easier to understand.
>
> Changes:
> - four small helper functions added
> - minor code reformatting in several places for readability
> - unnecessarily increasing string size has been fixed
>
> This patch should not change the behaviour of the Smack in any way.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Reviewed-by: Casey Schaufler <ca...@schaufler-ca.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  security/smack/smack.h| 47 ++-
>  security/smack/smack_access.c | 18 +-
>  security/smack/smack_lsm.c| 58 
> ---
>  security/smack/smackfs.c  |  4 +--
>  4 files changed, 81 insertions(+), 46 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 091efc2..98bb676 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -291,7 +291,7 @@ struct smk_audit_info {
>  int smk_access_entry(char *, char *, struct list_head *);
>  int smk_access(struct smack_known *, struct smack_known *,
>  int, struct smk_audit_info *);
> -int smk_tskacc(struct task_smack *, struct smack_known *,
> +int smk_tskacc(struct task_struct *, struct smack_known *,
>  u32, struct smk_audit_info *);
>  int smk_curacc(struct smack_known *, u32, struct smk_audit_info *);
>  struct smack_known *smack_from_secid(const u32);
> @@ -348,6 +348,7 @@ extern struct hlist_head 
> smack_known_hash[SMACK_HASH_SLOTS];
>  static inline int smk_inode_transmutable(const struct inode *isp)
>  {
>   struct inode_smack *sip = isp->i_security;
> +
>   return (sip->smk_flags & SMK_INODE_TRANSMUTE) != 0;
>  }
>  
> @@ -357,10 +358,31 @@ static inline int smk_inode_transmutable(const struct 
> inode *isp)
>  static inline struct smack_known *smk_of_inode(const struct inode *isp)
>  {
>   struct inode_smack *sip = isp->i_security;
> +
>   return sip->smk_inode;
>  }
>  
>  /*
> + * Present a pointer to the smack label entry in an inode blob for an exec.
> + */
> +static inline struct smack_known *smk_of_exec(const struct inode *isp)
> +{
> + struct inode_smack *sip = isp->i_security;
> +
> + return sip->smk_task;
> +}
> +
> +/*
> + * Present a pointer to the smack label entry in an inode blob for an mmap.
> + */
> +static inline struct smack_known *smk_of_mmap(const struct inode *isp)
> +{
> + struct inode_smack *sip = isp->i_security;
> +
> + return sip->smk_mmap;
> +}
> +
> +/*
>   * Present a pointer to the smack label entry in an task blob.
>   */
>  static inline struct smack_known *smk_of_task(const struct task_smack *tsp)
> @@ -395,6 +417,29 @@ static inline struct smack_known *smk_of_current(void)
>  }
>  
>  /*
> + * Present a pointer to the user namespace entry in an task blob.
> + */
> +static inline
> +struct user_namespace *ns_of_task_struct(const struct task_struct *t)
> +{
> + struct user_namespace *ns;
> +
> + rcu_read_lock();
> + ns = __task_cred(t)->user_ns;
> + rcu_read_unlock();
> +
> + return ns;
> +}
> +
> +/*
> + * Present a pointer to the user namespace entry in the current task blob.
> + */
> +static inline struct user_namespace *ns_of_current(void)
> +{
> + return current_user_ns();
> +}
> +
> +/*
>   * logging functions
>   */
>  #define SMACK_AUDIT_DENIED 0x1
> diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
> index 131c742..750aa9c 100644
> --- a/security/smack/smack_access.c
> +++ b/security/smack/smack_access.c
> @@ -167,6 +167,7 @@ int smk_access(struct smack_known *subject, struct 
> smack_known *object,
>   if (subject == _known_hat)
>   goto out_audit;
>   }
> +
>   /*
>* Beyond here an explicit relationship is required.
>* If the requested access is contained in the available
> @@ -183,6 +184,7 @@ int smk_access(struct smack_known *subject, struct 
> smack_known *object,
>   rc = -EACCES;
>   goto out_audit;
>   }
> +
>  #ifdef CONFIG_SECURITY_SMACK_BRINGUP
>   /*
>* Return a positive value if using bringup mode.
> @@ -225,10 +227,10 @@ out_audit:
>   * non zero otherwise. It allows that the task may have the capability
>   * to override

Re: [PATCH v4 01/11] user_ns: 3 new LSM hooks for user namespace operations

[Casey Schaufler]

On 10/14/2015 5:41 AM, Lukasz Pawelczyk wrote:
> This commit implements 3 new LSM hooks that provide the means for LSMs
> to embed their own security context within user namespace, effectively
> creating some sort of a user_ns related security namespace.
>
> The first one to take advantage of this mechanism is Smack.
>
> The hooks has been documented in the in the security.h below.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Reviewed-by: Casey Schaufler <ca...@schaufler-ca.com>
> Acked-by: Paul Moore <p...@paul-moore.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>

> ---
>  include/linux/lsm_hooks.h  | 28 
>  include/linux/security.h   | 23 +++
>  include/linux/user_namespace.h |  4 
>  kernel/user.c  |  3 +++
>  kernel/user_namespace.c| 18 ++
>  security/security.c| 28 
>  6 files changed, 104 insertions(+)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index ec3a6ba..18c9160 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1261,6 +1261,23 @@
>   *   audit_rule_init.
>   *   @rule contains the allocated rule
>   *
> + * @userns_create:
> + *   Allocates and fills the security part of a new user namespace.
> + *   @ns points to a newly created user namespace.
> + *   Returns 0 or an error code.
> + *
> + * @userns_free:
> + *   Deallocates the security part of a user namespace.
> + *   @ns points to a user namespace about to be destroyed.
> + *
> + * @userns_setns:
> + *   Run during a setns syscall to add a process to an already existing
> + *   user namespace. Returning failure here will block the operation
> + *   requested from userspace (setns() with CLONE_NEWUSER).
> + *   @nsproxy contains nsproxy to which the user namespace will be assigned.
> + *   @ns contains user namespace that is to be incorporated to the nsproxy.
> + *   Returns 0 or an error code.
> + *
>   * @inode_notifysecctx:
>   *   Notify the security module of what the security context of an inode
>   *   should be.  Initializes the incore security context managed by the
> @@ -1613,6 +1630,12 @@ union security_list_options {
>   struct audit_context *actx);
>   void (*audit_rule_free)(void *lsmrule);
>  #endif /* CONFIG_AUDIT */
> +
> +#ifdef CONFIG_USER_NS
> + int (*userns_create)(struct user_namespace *ns);
> + void (*userns_free)(struct user_namespace *ns);
> + int (*userns_setns)(struct nsproxy *nsproxy, struct user_namespace *ns);
> +#endif /* CONFIG_USER_NS */
>  };
>  
>  struct security_hook_heads {
> @@ -1824,6 +1847,11 @@ struct security_hook_heads {
>   struct list_head audit_rule_match;
>   struct list_head audit_rule_free;
>  #endif /* CONFIG_AUDIT */
> +#ifdef CONFIG_USER_NS
> + struct list_head userns_create;
> + struct list_head userns_free;
> + struct list_head userns_setns;
> +#endif /* CONFIG_USER_NS */
>  };
>  
>  /*
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 2f4c1f7..91ffba2 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1584,6 +1584,29 @@ static inline void security_audit_rule_free(void 
> *lsmrule)
>  #endif /* CONFIG_SECURITY */
>  #endif /* CONFIG_AUDIT */
>  
> +#ifdef CONFIG_USER_NS
> +int security_userns_create(struct user_namespace *ns);
> +void security_userns_free(struct user_namespace *ns);
> +int security_userns_setns(struct nsproxy *nsproxy, struct user_namespace 
> *ns);
> +
> +#else
> +
> +static inline int security_userns_create(struct user_namespace *ns)
> +{
> + return 0;
> +}
> +
> +static inline void security_userns_free(struct user_namespace *ns)
> +{ }
> +
> +static inline int security_userns_setns(struct nsproxy *nsproxy,
> + struct user_namespace *ns)
> +{
> + return 0;
> +}
> +
> +#endif /* CONFIG_USER_NS */
> +
>  #ifdef CONFIG_SECURITYFS
>  
>  extern struct dentry *securityfs_create_file(const char *name, umode_t mode,
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index 8297e5b..a9400cc 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -39,6 +39,10 @@ struct user_namespace {
>   struct key  *persistent_keyring_register;
>   struct rw_semaphore persistent_keyring_register_sem;
>  #endif
> +
> +#ifdef CONFIG_SECURITY
> + void *security;
> +#endif
>  };
>  
>  extern struct user_namespace init_user_ns;

Re: [PATCH v4 06/11] smack: don't use implicit star to display smackfs/syslog

[Casey Schaufler]

On 10/14/2015 5:42 AM, Lukasz Pawelczyk wrote:
> Smackfs/syslog is analogous to onlycap and unconfined. When not filled
> they don't do anything. In such cases onlycap and unconfined displayed
> nothing when read, but syslog unconditionally displayed star. This
> doesn't work well with namespaces where the star could have been
> unmapped. Besides the meaning of this star was different then a star
> that could be written to this file. This was misleading.
>
> This also brings syslog read/write functions on par with onlycap and
> unconfined where it is possible to reset the value to NULL as should be
> possible according to comment in smackfs.c describing smack_syslog_label
> variable.
>
> Before that the initial state was to allow (smack_syslog_label was
> NULL), but after writing star to it the current had to be labeled star
> as well to have an access, even thought reading the smackfs/syslog
> returned the same result in both cases.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Acked-by: Serge Hallyn <serge.hal...@canonical.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  security/smack/smackfs.c | 42 +++---
>  1 file changed, 27 insertions(+), 15 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index ce8d503..05e09ee2 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -2634,23 +2634,20 @@ static const struct file_operations 
> smk_change_rule_ops = {
>  static ssize_t smk_read_syslog(struct file *filp, char __user *buf,
>   size_t cn, loff_t *ppos)
>  {
> - struct smack_known *skp;
> + char *smack = "";
>   ssize_t rc = -EINVAL;
>   int asize;
>  
>   if (*ppos != 0)
>   return 0;
>  
> - if (smack_syslog_label == NULL)
> - skp = _known_star;
> - else
> - skp = smack_syslog_label;
> + if (smack_syslog_label != NULL)
> + smack = smack_syslog_label->smk_known;
>  
> - asize = strlen(skp->smk_known) + 1;
> + asize = strlen(smack) + 1;
>  
>   if (cn >= asize)
> - rc = simple_read_from_buffer(buf, cn, ppos, skp->smk_known,
> - asize);
> + rc = simple_read_from_buffer(buf, cn, ppos, smack, asize);
>  
>   return rc;
>  }
> @@ -2678,16 +2675,31 @@ static ssize_t smk_write_syslog(struct file *file, 
> const char __user *buf,
>   if (data == NULL)
>   return -ENOMEM;
>  
> - if (copy_from_user(data, buf, count) != 0)
> + if (copy_from_user(data, buf, count) != 0) {
>   rc = -EFAULT;
> - else {
> - skp = smk_import_entry(data, count);
> - if (IS_ERR(skp))
> - rc = PTR_ERR(skp);
> - else
> - smack_syslog_label = skp;
> + goto freeout;
>   }
>  
> + /*
> +  * Clear the smack_syslog_label on invalid label errors. This means
> +  * that we can pass a null string to unset the syslog value.
> +  *
> +  * Importing will also reject a label beginning with '-',
> +  * so "-syslog" will also work.
> +  *
> +  * But do so only on invalid label, not on system errors.
> +  */
> + skp = smk_import_entry(data, count);
> + if (PTR_ERR(skp) == -EINVAL)
> + skp = NULL;
> + else if (IS_ERR(skp)) {
> + rc = PTR_ERR(skp);
> + goto freeout;
> + }
> +
> + smack_syslog_label = skp;
> +
> +freeout:
>   kfree(data);
>   return rc;
>  }

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 03/11] lsm: add file opener's cred to a setprocattr arguments

[Casey Schaufler]

On 10/14/2015 5:41 AM, Lukasz Pawelczyk wrote:
> setprocattr hook for Smack's label_map attribute needs to know the
> capabilities of file opener. Add those credentials to the hook's
> arguments.
>
> While at it add documentation on get/setprocattr hooks.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Acked-by: Serge Hallyn <serge.hal...@canonical.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  fs/proc/base.c |  2 +-
>  include/linux/lsm_hooks.h  | 18 --
>  include/linux/security.h   |  7 +--
>  security/apparmor/lsm.c|  5 +++--
>  security/security.c|  6 --
>  security/selinux/hooks.c   |  2 +-
>  security/smack/smack_lsm.c |  4 ++--
>  7 files changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 9ec88b8..2b38969 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2447,7 +2447,7 @@ static ssize_t proc_pid_attr_write(struct file * file, 
> const char __user * buf,
>   if (length < 0)
>   goto out_free;
>  
> - length = security_setprocattr(task,
> + length = security_setprocattr(task, file->f_cred,
> (char*)file->f_path.dentry->d_name.name,
> (void*)page, count);
>   mutex_unlock(>signal->cred_guard_mutex);
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 7049db0..4f16640 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1220,6 +1220,20 @@
>   *   Return 0 if @name is to be handled by seq, EOPNOTSUPP if getprocattr()
>   *   should be used. Other errors will be passed to user-space.
>   *
> + * @getprocattr:
> + *   Get a value of a proc security attribute in /proc/$PID/attr/.
> + *   @p a task associated with the proc file.
> + *   @name a name of the file in question.
> + *   @value a pointer where to return the attribute's value.
> + *
> + * @setprocattr:
> + *   Set a value of a proc security attribute in /proc/$PID/attr/.
> + *   @p a task associated with the proc file.
> + *   @f_cred credentials of a file's opener.
> + *   @name a name of the file in question.
> + *   @value a pointer where a value to set is kept.
> + *   @size a number of bytes to read from the @value pointer.
> + *
>   * @secid_to_secctx:
>   *   Convert secid to security context.  If secdata is NULL the length of
>   *   the result will be returned in seclen, but no secdata will be returned.
> @@ -1540,8 +1554,8 @@ union security_list_options {
>   int (*getprocattr_seq)(struct task_struct *p, const char *name,
>  const struct seq_operations **ops);
>   int (*getprocattr)(struct task_struct *p, char *name, char **value);
> - int (*setprocattr)(struct task_struct *p, char *name, void *value,
> - size_t size);
> + int (*setprocattr)(struct task_struct *p, const struct cred *f_cred,
> +char *name, void *value, size_t size);
>   int (*ismaclabel)(const char *name);
>   int (*secid_to_secctx)(u32 secid, char **secdata, u32 *seclen);
>   int (*secctx_to_secid)(const char *secdata, u32 seclen, u32 *secid);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index dddea2f..12bd011 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -348,7 +348,8 @@ void security_d_instantiate(struct dentry *dentry, struct 
> inode *inode);
>  int security_getprocattr_seq(struct task_struct *p, const char *name,
>const struct seq_operations **ops);
>  int security_getprocattr(struct task_struct *p, char *name, char **value);
> -int security_setprocattr(struct task_struct *p, char *name, void *value, 
> size_t size);
> +int security_setprocattr(struct task_struct *p, const struct cred *f_cred,
> +  char *name, void *value, size_t size);
>  int security_netlink_send(struct sock *sk, struct sk_buff *skb);
>  int security_ismaclabel(const char *name);
>  int security_secid_to_secctx(u32 secid, char **secdata, u32 *seclen);
> @@ -1071,7 +1072,9 @@ static inline int security_getprocattr(struct 
> task_struct *p, char *name, char *
>   return -EINVAL;
>  }
>  
> -static inline int security_setprocattr(struct task_struct *p, char *name, 
> void *value, size_t size)
> +static inline int security_setprocattr(struct task_struct *p,
> +const struct cred *f_cred,
> +char *name, void *value, size_t size)
>  {
>   return -EINVAL;
>  }
> diff --git a/security/appa

Re: [PATCH v4 04/11] lsm: inode_pre_setxattr hook

[Casey Schaufler]

On 10/14/2015 5:41 AM, Lukasz Pawelczyk wrote:
> Add a new LSM hook called before inode's setxattr. It is required for
> LSM to be able to reliably replace the xattr's value to be set to
> filesystem in __vfs_setxattr_noperm(). Useful for mapped values, like in
> the upcoming Smack namespace patches.
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>
> Acked-by: Serge Hallyn <serge.hal...@canonical.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>


> ---
>  fs/xattr.c| 10 ++
>  include/linux/lsm_hooks.h |  9 +
>  include/linux/security.h  | 10 ++
>  security/security.c   | 12 
>  4 files changed, 41 insertions(+)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 072fee1..cbc8d19 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -100,12 +100,22 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const 
> char *name,
>   if (issec)
>   inode->i_flags &= ~S_NOSEC;
>   if (inode->i_op->setxattr) {
> + bool alloc = false;
> +
> + error = security_inode_pre_setxattr(dentry, name, ,
> + , flags, );
> + if (error)
> + return error;
> +
>   error = inode->i_op->setxattr(dentry, name, value, size, flags);
>   if (!error) {
>   fsnotify_xattr(dentry);
>   security_inode_post_setxattr(dentry, name, value,
>size, flags);
>   }
> +
> + if (alloc)
> + kfree(value);
>   } else if (issec) {
>   const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
>   error = security_inode_setsecurity(inode, suffix, value,
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 4f16640..85bfdde 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -349,6 +349,11 @@
>   *   Check permission before setting the extended attributes
>   *   @value identified by @name for @dentry.
>   *   Return 0 if permission is granted.
> + * @inode_pre_setxattr:
> + *   Be able to do some operation before setting the @value identified
> + *   by @name on the filesystem. Replacing the @value and its @size is
> + *   possible. Useful for mapped values. Set @alloc to true if @value
> + *   needs to be kfreed afterwards.
>   * @inode_post_setxattr:
>   *   Update inode security field after successful setxattr operation.
>   *   @value identified by @name for @dentry.
> @@ -1448,6 +1453,9 @@ union security_list_options {
>   int (*inode_getattr)(const struct path *path);
>   int (*inode_setxattr)(struct dentry *dentry, const char *name,
>   const void *value, size_t size, int flags);
> + int (*inode_pre_setxattr)(struct dentry *dentry, const char *name,
> +   const void **value, size_t *size,
> +   int flags, bool *alloc);
>   void (*inode_post_setxattr)(struct dentry *dentry, const char *name,
>   const void *value, size_t size,
>   int flags);
> @@ -1730,6 +1738,7 @@ struct security_hook_heads {
>   struct list_head inode_setattr;
>   struct list_head inode_getattr;
>   struct list_head inode_setxattr;
> + struct list_head inode_pre_setxattr;
>   struct list_head inode_post_setxattr;
>   struct list_head inode_getxattr;
>   struct list_head inode_listxattr;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 12bd011..4de4865 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -263,6 +263,9 @@ int security_inode_setattr(struct dentry *dentry, struct 
> iattr *attr);
>  int security_inode_getattr(const struct path *path);
>  int security_inode_setxattr(struct dentry *dentry, const char *name,
>   const void *value, size_t size, int flags);
> +int security_inode_pre_setxattr(struct dentry *dentry, const char *name,
> + const void **value, size_t *size, int flags,
> + bool *alloc);
>  void security_inode_post_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags);
>  int security_inode_getxattr(struct dentry *dentry, const char *name);
> @@ -691,6 +694,13 @@ static inline int security_inode_setxattr(struct dentry 
> *dentry,
>   return cap_inode_setxattr(dentry, name, value, size, flags);
>  }
>  
> +static inline

Re: [PATCH v5] Smack: limited capability for changing process label

[Casey Schaufler]

On 10/19/2015 9:23 AM, Rafal Krypa wrote:
> From: Zbigniew Jasinski <z.jasin...@samsung.com>
>
> This feature introduces new kernel interface:
>
> - /relabel-self - for setting transition labels list
>
> This list is used to control smack label transition mechanism.
> List is set by, and per process. Process can transit to new label only if
> label is on the list. Only process with CAP_MAC_ADMIN capability can add
> labels to this list. With this list, process can change it's label without
> CAP_MAC_ADMIN but only once. After label changing, list is unset.
>
> Changes in v2:
> * use list_for_each_entry instead of _rcu during label write
> * added missing description in security/Smack.txt
>
> Changes in v3:
> * squashed into one commit
>
> Changes in v4:
> * switch from global list to per-task list
> * since the per-task list is accessed only by the task itself
>   there is no need to use synchronization mechanisms on it
>
> Changes in v5:
> * change smackfs interface of relabel-self to the one used for onlycap
>   multiple labels are accepted, separated by space, which
>   replace the previous list upon write
>
> Signed-off-by: Zbigniew Jasinski <z.jasin...@samsung.com>
> Signed-off-by: Rafal Krypa <r.kr...@samsung.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>
Applied-to: https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  Documentation/security/Smack.txt |  10 ++
>  security/smack/smack.h   |   4 +-
>  security/smack/smack_access.c|   6 +-
>  security/smack/smack_lsm.c   |  57 ++-
>  security/smack/smackfs.c | 202 
> ---
>  5 files changed, 238 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/security/Smack.txt 
> b/Documentation/security/Smack.txt
> index 5e6d07f..945cc63 100644
> --- a/Documentation/security/Smack.txt
> +++ b/Documentation/security/Smack.txt
> @@ -255,6 +255,16 @@ unconfined
>   the access permitted if it wouldn't be otherwise. Note that this
>   is dangerous and can ruin the proper labeling of your system.
>   It should never be used in production.
> +relabel-self
> + This interface contains a list of labels to which the process can
> + transition to, by writing to /proc/self/attr/current.
> + Normally a process can change its own label to any legal value, but only
> + if it has CAP_MAC_ADMIN. This interface allows a process without
> + CAP_MAC_ADMIN to relabel itself to one of labels from predefined list.
> + A process without CAP_MAC_ADMIN can change its label only once. When it
> + does, this list will be cleared.
> + The values are set by writing the desired labels, separated
> + by spaces, to the file or cleared by writing "-" to the file.
>  
>  If you are using the smackload utility
>  you can add access rules in /etc/smack/accesses. They take the form:
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index fff0c61..6c91156 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -115,6 +115,7 @@ struct task_smack {
>   struct smack_known  *smk_forked;/* label when forked */
>   struct list_headsmk_rules;  /* per task access rules */
>   struct mutexsmk_rules_lock; /* lock for the rules */
> + struct list_headsmk_relabel;/* transit allowed labels */
>  };
>  
>  #define  SMK_INODE_INSTANT   0x01/* inode is instantiated */
> @@ -169,7 +170,7 @@ struct smk_port_label {
>  };
>  #endif /* SMACK_IPV6_PORT_LABELING */
>  
> -struct smack_onlycap {
> +struct smack_known_list_elem {
>   struct list_headlist;
>   struct smack_known  *smk_label;
>  };
> @@ -301,6 +302,7 @@ struct smack_known *smk_import_entry(const char *, int);
>  void smk_insert_entry(struct smack_known *skp);
>  struct smack_known *smk_find_entry(const char *);
>  int smack_privileged(int cap);
> +void smk_destroy_label_list(struct list_head *list);
>  
>  /*
>   * Shared data.
> diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
> index bc1053f..a283f9e 100644
> --- a/security/smack/smack_access.c
> +++ b/security/smack/smack_access.c
> @@ -637,7 +637,7 @@ DEFINE_MUTEX(smack_onlycap_lock);
>  int smack_privileged(int cap)
>  {
>   struct smack_known *skp = smk_of_current();
> - struct smack_onlycap *sop;
> + struct smack_known_list_elem *sklep;
>  
>   /*
>* All kernel tasks are privileged
> @@ -654,8 +654,8 @@ int smack_privileged(int cap)
>   return 1;
>   }
>  
> - list_for_each_entry_rcu(sop, _onlycap_list

[PULL] Smack - Changes for 4.4

[Casey Schaufler]

The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  https://github.com/cschaufler/smack-next.git smack-for-4.4

for you to fetch changes up to 38416e53936ecf896948fdeffc36b76979117952:

  Smack: limited capability for changing process label (2015-10-19
12:06:47 -0700)


Geliang Tang (1):
  smack: smk_ipv6_port_list should be static

José Bollo (1):
  Smack: Minor initialisation improvement

Lukasz Pawelczyk (1):
  Smack: fix a NULL dereference in wrong smack_import_entry() usage

Roman Kubiak (1):
  Smack: pipefs fix in smack_d_instantiate

Zbigniew Jasinski (1):
  Smack: limited capability for changing process label

 Documentation/security/Smack.txt |  10 ++
 security/smack/smack.h   |   4 +-
 security/smack/smack_access.c|   6 +-
 security/smack/smack_lsm.c   |  67 -
 security/smack/smackfs.c | 208
---
 5 files changed, 248 insertions(+), 47 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] Smack: limited capability for changing process label

[Casey Schaufler]

On 10/15/2015 12:48 AM, Rafał Krypa wrote:
> On 2015-10-14 17:54, Rafal Krypa wrote:
>> From: Zbigniew Jasinski 
>>
>> This feature introduces new kernel interface:
>>
>> - /relabel-self - for setting transition labels list
>>
>> This list is used to control smack label transition mechanism.
>> List is set by, and per process. Process can transit to new label only if
>> label is on the list. Only process with CAP_MAC_ADMIN capability can add
>> labels to this list. With this list, process can change it's label without
>> CAP_MAC_ADMIN but only once. After label changing, list is unset.
>>
>> Changes in v2:
>> * use list_for_each_entry instead of _rcu during label write
>> * added missing description in security/Smack.txt
>>
>> Changes in v3:
>> * squashed into one commit
>>
>> Changes in v4:
>> * switch from global list to per-task list
>> * since the per-task list is accessed only by the task itself
>>   there is no need to use synchronization mechanisms on it
>>
>> Signed-off-by: Zbigniew Jasinski 
>> Signed-off-by: Rafal Krypa 
>> ---
>>  Documentation/security/Smack.txt |  14 
>>  security/smack/smack.h   |   3 +-
>>  security/smack/smack_access.c|   6 +-
>>  security/smack/smack_lsm.c   |  73 -
>>  security/smack/smackfs.c | 167 
>> ---
>>  5 files changed, 246 insertions(+), 17 deletions(-)
>>
>> diff --git a/Documentation/security/Smack.txt 
>> b/Documentation/security/Smack.txt
>> index 5e6d07f..d9ace08 100644
>> --- a/Documentation/security/Smack.txt
>> +++ b/Documentation/security/Smack.txt
>> @@ -255,6 +255,20 @@ unconfined
>>  the access permitted if it wouldn't be otherwise. Note that this
>>  is dangerous and can ruin the proper labeling of your system.
>>  It should never be used in production.
>> +relabel-self
>> +This interface contains a list of labels to which the process can
>> +transition to, by writing to /proc/self/attr/current.
>> +Normally a process can change its own label to any legal value, but only
>> +if it has CAP_MAC_ADMIN. This interface allows a process without
>> +CAP_MAC_ADMIN to relabel itself to one of labels from predefined list.
>> +A process without CAP_MAC_ADMIN can change its label only once. When it
>> +does, this list will be cleared.
>> +
>> +The format accepted on write is:
>> +"%s"
>> +for adding label, and:
>> +"-%s"
>> +for removing label from list.
> I have one concern here, let me make some self-criticism.
> The interface described here for relabel-self is convenient and suiting 
> actual needs of user space parts that are going to use it.
> But it is inconsistent with other existing interfaces in smackfs. Recently I 
> submitted a patch (merged into v4.2) that extended onlycap to allow multiple 
> labels in it.
> The smackfs interface for onlycap always takes the full list of labels that 
> replaces the list that was previously set.
> Now relabel-self is also going to contain a list of labels. But smackfs 
> interface gets one label at a time and performs add/remove operations.
>
> Are you OK. with such inconsistency?
>
A foolish consistency is the hobgoblin of little minds.

More directly, I am fine with it. Some of your previous work
made removing labels from lists practical where it had not been
before. I would rather have an inconsistent interface set
than one that is consistently bad.

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/7] Smack: Handle labels consistently in untrusted mounts

[Casey Schaufler]

On 10/13/2015 10:04 AM, Seth Forshee wrote:
> The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
> differently in untrusted mounts. This is confusing and
> potentically problematic. Change this to handle them all the same
> way that SMACK64 is currently handled; that is, read the label
> from disk and check it at use time. For SMACK64 and SMACK64MMAP
> access is denied if the label does not match smk_root. To be
> consistent with suid, a SMACK64EXEC label which does not match
> smk_root will still allow execution of the file but will not run
> with the label supplied in the xattr.
>
> Signed-off-by: Seth Forshee 

Aside from the one comment below (which I can be talked out of)
this looks fine.

> ---
>  security/smack/smack_lsm.c | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 621200f86b56..bee0b2652bf4 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -891,6 +891,7 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
>   struct inode *inode = file_inode(bprm->file);
>   struct task_smack *bsp = bprm->cred->security;
>   struct inode_smack *isp;
> + struct superblock_smack *sbsp;
>   int rc;
>  
>   if (bprm->cred_prepared)
> @@ -900,6 +901,10 @@ static int smack_bprm_set_creds(struct linux_binprm 
> *bprm)
>   if (isp->smk_task == NULL || isp->smk_task == bsp->smk_task)
>   return 0;
>  
> + sbsp = inode->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED && isp->smk_task != 
> sbsp->smk_root)

Call me old fashioned, but how about

if ((sbsp->smk_flags & SMK_SB_UNTRUSTED) && isp->smk_task != 
sbsp->smk_root)

naked '&'s give me the willies. 

> + return 0;
> +
>   if (bprm->unsafe & (LSM_UNSAFE_PTRACE | LSM_UNSAFE_PTRACE_CAP)) {
>   struct task_struct *tracer;
>   rc = 0;
> @@ -1703,6 +1708,7 @@ static int smack_mmap_file(struct file *file,
>   struct task_smack *tsp;
>   struct smack_known *okp;
>   struct inode_smack *isp;
> + struct superblock_smack *sbsp;
>   int may;
>   int mmay;
>   int tmay;
> @@ -1714,6 +1720,10 @@ static int smack_mmap_file(struct file *file,
>   isp = file_inode(file)->i_security;
>   if (isp->smk_mmap == NULL)
>   return 0;
> + sbsp = file_inode(file)->i_sb->s_security;
> + if (sbsp->smk_flags & SMK_SB_UNTRUSTED &&
> + isp->smk_mmap != sbsp->smk_root)
> + return -EACCES;
>   mkp = isp->smk_mmap;
>  
>   tsp = current_security();
> @@ -3492,16 +3502,14 @@ static void smack_d_instantiate(struct dentry 
> *opt_dentry, struct inode *inode)
>   if (rc >= 0)
>   transflag = SMK_INODE_TRANSMUTE;
>   }
> - if (!(sbsp->smk_flags & SMK_SB_UNTRUSTED)) {
> - /*
> -  * Don't let the exec or mmap label be "*" or "@".
> -  */
> - skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> - if (IS_ERR(skp) || skp == _known_star ||
> - skp == _known_web)
> - skp = NULL;
> - isp->smk_task = skp;
> - }
> + /*
> +  * Don't let the exec or mmap label be "*" or "@".
> +  */
> + skp = smk_fetch(XATTR_NAME_SMACKEXEC, inode, dp);
> + if (IS_ERR(skp) || skp == _known_star ||
> + skp == _known_web)
> + skp = NULL;
> + isp->smk_task = skp;
>  
>   skp = smk_fetch(XATTR_NAME_SMACKMMAP, inode, dp);
>   if (IS_ERR(skp) || skp == _known_star ||

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Smack: fix a NULL dereference in wrong smack_import_entry() usage

[Casey Schaufler]

On 8/25/2015 3:39 AM, Lukasz Pawelczyk wrote:
> The e774ad683f425a51f87711164ea166d9dcc41477 commit made this function
> return proper error codes instead of NULL. Reflect that.
>
> This is a fix for a NULL dereference introduced in
> 21abb1ec414c75abe32c3854848ff30e2b4a6113:
>
> echo "$SOME_IPV6_ADDR \"test" > /smack/ipv6host
>   (this should return EINVAL, it doesn't)
> cat /smack/ipv6host
>   (derefences 0x000a)
>
> Signed-off-by: Lukasz Pawelczyk <l.pawelc...@samsung.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smackfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index c20b154..103a619 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -1501,8 +1501,8 @@ static ssize_t smk_write_net6addr(struct file *file, 
> const char __user *buf,
>*/
>   if (smack[0] != '-') {
>   skp = smk_import_entry(smack, 0);
> - if (skp == NULL) {
> - rc = -EINVAL;
> + if (IS_ERR(skp)) {
> + rc = PTR_ERR(skp);
>   goto free_out;
>   }
>   } else {

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] smack: smk_ipv6_port_list should be static

[Casey Schaufler]

On 9/27/2015 8:10 AM, Geliang Tang wrote:
> Fixes the following sparse warning:
>
>  security/smack/smack_lsm.c:55:1: warning: symbol 'smk_ipv6_port_list'
>  was not declared. Should it be static?
>
> Signed-off-by: Geliang Tang <geliangt...@163.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smack_lsm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 996c889..f02438c 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -52,7 +52,7 @@
>  #define SMK_SENDING  2
>  
>  #ifdef SMACK_IPV6_PORT_LABELING
> -LIST_HEAD(smk_ipv6_port_list);
> +static LIST_HEAD(smk_ipv6_port_list);
>  #endif
>  static struct kmem_cache *smack_inode_cache;
>  int smack_enabled;

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Smack: Minor initialisation improvement

[Casey Schaufler]

On 10/2/2015 6:15 AM, José Bollo wrote:
> This change has two goals:
>  - delay the setting of 'smack_enabled' until
>it will be really effective
>  - ensure that smackfs is valid only if 'smack_enabled'
>is set (it is already the case in smack_netfilter.c)
>
> Signed-off-by: José Bollo <jose.bo...@iot.bzh>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smack_lsm.c | 4 ++--
>  security/smack/smackfs.c   | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 996c889..dd0f0a6 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -4708,8 +4708,6 @@ static __init int smack_init(void)
>   if (!security_module_enable("smack"))
>   return 0;
>  
> - smack_enabled = 1;
> -
>   smack_inode_cache = KMEM_CACHE(inode_smack, 0);
>   if (!smack_inode_cache)
>   return -ENOMEM;
> @@ -4721,6 +4719,8 @@ static __init int smack_init(void)
>   return -ENOMEM;
>   }
>  
> + smack_enabled = 1;
> +
>   pr_info("Smack:  Initializing.\n");
>  #ifdef CONFIG_SECURITY_SMACK_NETFILTER
>   pr_info("Smack:  Netfilter enabled.\n");
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index c20b154..d2bb5ee 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -2892,7 +2892,7 @@ static int __init init_smk_fs(void)
>   int err;
>   int rc;
>  
> - if (!security_module_enable("smack"))
> + if (smack_enabled == 0)
>   return 0;
>  
>   err = smk_init_sysfs();

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Smack: pipefs fix in smack_d_instantiate

[Casey Schaufler]

On 10/5/2015 3:27 AM, Roman Kubiak wrote:
> This fix writes the task label when
> smack_d_instantiate is called, before the
> label of the superblock was written on the
> pipe's inode.
>
> Signed-off-by: Roman Kubiak <r.kub...@samsung.com>

Acked-by: Casey Schaufler <ca...@schaufler-ca.com>
Applied to https://github.com/cschaufler/smack-next.git#smack-for-4.4

> ---
>  security/smack/smack_lsm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 996c889..f1d6ef1 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3354,6 +3354,9 @@ static void smack_d_instantiate(struct dentry 
> *opt_dentry, struct inode *inode)
>*/
>   isp->smk_inode = smk_of_current();
>   break;
> + case PIPEFS_MAGIC:
> + isp->smk_inode = smk_of_current();
> + break;
>   default:
>   isp->smk_inode = sbsp->smk_root;
>   break;

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Smack: Fix wrong copy size

[Casey Schaufler]

On 10/2/2015 6:19 AM, José Bollo wrote:
> The function strncpy was copying an extra character
> when i == len (what is possible via revoke interface).
>
> Change-Id: Ic7452da05773e620a1d7bbc55e859c25a86c65f6
> Signed-off-by: José Bollo 
> Signed-off-by: Stephane Desneux 

Thank you for the patch. It appears that Lukasz Pawelczyk
had a fix for this already.

> ---
>  security/smack/smack_access.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/smack/smack_access.c
> b/security/smack/smack_access.c
> index c062e94..930e548 100644
> --- a/security/smack/smack_access.c
> +++ b/security/smack/smack_access.c
> @@ -432,7 +432,7 @@ char *smk_parse_smack(const char *string, int len)
>  
>   smack = kzalloc(i + 1, GFP_KERNEL);
>   if (smack != NULL) {
> - strncpy(smack, string, i + 1);
> + strncpy(smack, string, i);
>   smack[i] = '\0';
>   }
>   return smack;

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] security: Add hook to invalidate inode security labels

[Casey Schaufler]

On 10/4/2015 12:19 PM, Andreas Gruenbacher wrote:
> Add a hook to invalidate an inode's security label when the cached
> information becomes invalid.

Where is this used? If I need to do the same for Smack
or any other module, how would I know that it works right?

>
> Implement the new hook in selinux: set a flag when a security label becomes
> invalid.  When hitting a security label which has been marked as invalid in
> inode_has_perm, try reloading the label.
>
> If an inode does not have any dentries attached, we cannot reload its
> security label because we cannot use the getxattr inode operation.  In that
> case, continue using the old, invalid label until a dentry becomes
> available.
>
> Signed-off-by: Andreas Gruenbacher 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Eric Paris 
> Cc: seli...@tycho.nsa.gov
> ---
>  include/linux/lsm_hooks.h |  6 ++
>  include/linux/security.h  |  5 +
>  security/security.c   |  8 
>  security/selinux/hooks.c  | 23 +--
>  security/selinux/include/objsec.h |  3 ++-
>  5 files changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index ec3a6ba..945ae1d 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1261,6 +1261,10 @@
>   *   audit_rule_init.
>   *   @rule contains the allocated rule
>   *
> + * @inode_invalidate_secctx:
> + *   Notify the security module that it must revalidate the security context
> + *   of an inode.
> + *
>   * @inode_notifysecctx:
>   *   Notify the security module of what the security context of an inode
>   *   should be.  Initializes the incore security context managed by the
> @@ -1516,6 +1520,7 @@ union security_list_options {
>   int (*secctx_to_secid)(const char *secdata, u32 seclen, u32 *secid);
>   void (*release_secctx)(char *secdata, u32 seclen);
>  
> + void (*inode_invalidate_secctx)(struct inode *inode);
>   int (*inode_notifysecctx)(struct inode *inode, void *ctx, u32 ctxlen);
>   int (*inode_setsecctx)(struct dentry *dentry, void *ctx, u32 ctxlen);
>   int (*inode_getsecctx)(struct inode *inode, void **ctx, u32 *ctxlen);
> @@ -1757,6 +1762,7 @@ struct security_hook_heads {
>   struct list_head secid_to_secctx;
>   struct list_head secctx_to_secid;
>   struct list_head release_secctx;
> + struct list_head inode_invalidate_secctx;
>   struct list_head inode_notifysecctx;
>   struct list_head inode_setsecctx;
>   struct list_head inode_getsecctx;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 2f4c1f7..9692571 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -353,6 +353,7 @@ int security_secid_to_secctx(u32 secid, char **secdata, 
> u32 *seclen);
>  int security_secctx_to_secid(const char *secdata, u32 seclen, u32 *secid);
>  void security_release_secctx(char *secdata, u32 seclen);
>  
> +void security_inode_invalidate_secctx(struct inode *inode);
>  int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
>  int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
>  int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
> @@ -1093,6 +1094,10 @@ static inline void security_release_secctx(char 
> *secdata, u32 seclen)
>  {
>  }
>  
> +static inline void security_inode_invalidate_secctx(struct inode *inode)
> +{
> +}
> +
>  static inline int security_inode_notifysecctx(struct inode *inode, void 
> *ctx, u32 ctxlen)
>  {
>   return -EOPNOTSUPP;
> diff --git a/security/security.c b/security/security.c
> index 46f405c..e4371cd 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1161,6 +1161,12 @@ void security_release_secctx(char *secdata, u32 seclen)
>  }
>  EXPORT_SYMBOL(security_release_secctx);
>  
> +void security_inode_invalidate_secctx(struct inode *inode)
> +{
> + call_void_hook(inode_invalidate_secctx, inode);
> +}
> +EXPORT_SYMBOL(security_inode_invalidate_secctx);
> +
>  int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen)
>  {
>   return call_int_hook(inode_notifysecctx, 0, inode, ctx, ctxlen);
> @@ -1763,6 +1769,8 @@ struct security_hook_heads security_hook_heads = {
>   LIST_HEAD_INIT(security_hook_heads.secctx_to_secid),
>   .release_secctx =
>   LIST_HEAD_INIT(security_hook_heads.release_secctx),
> + .inode_invalidate_secctx =
> + LIST_HEAD_INIT(security_hook_heads.inode_invalidate_secctx),
>   .inode_notifysecctx =
>   LIST_HEAD_INIT(security_hook_heads.inode_notifysecctx),
>   .inode_setsecctx =
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e4369d8..c5e4ca8 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1293,11 +1293,11 @@ static 

Re: [PATCH 06/37] Security: Separate task security context from task_struct

[Casey Schaufler]

';
  
   rc = smack_netlabel(sk);
 @@ -2285,7 +2286,7 @@ static int smack_inet_conn_request(struct sock *sk,
 struct sk_buff *skb,
  static int smack_key_alloc(struct key *key, struct task_struct *tsk,
  unsigned long flags)
  {
 - key-security = tsk-security;
 + key-security = tsk-act_as-security;
   return 0;
  }
  
 @@ -2326,10 +2327,11 @@ static int smack_key_permission(key_ref_t key_ref,
   /*
* This should not occur
*/
 - if (context-security == NULL)
 + if (context-act_as-security == NULL)
   return -EACCES;
  
 - return smk_access(context-security, keyp-security, MAY_READWRITE);
 + return smk_access(context-act_as-security, keyp-security,
 +   MAY_READWRITE);
  }
  #endif /* CONFIG_KEYS */
  
 @@ -2510,7 +2512,7 @@ static __init int smack_init(void)
   /*
* Set the security state for the initial task.
*/
 - current-security = smack_known_floor.smk_known;
 + current-sec-security = smack_known_floor.smk_known;
  
   /*
* Initialize locks
 diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
 index 358c92c..2cb3a5e 100644
 --- a/security/smack/smackfs.c
 +++ b/security/smack/smackfs.c
 @@ -345,7 +345,7 @@ void smk_cipso_doi(void)
   struct netlbl_audit audit_info;
  
   audit_info.loginuid = audit_get_loginuid(current);
 - audit_info.secid = smack_to_secid(current-security);
 + audit_info.secid = smack_to_secid(current-sec-security);
  
   rc = netlbl_cfg_map_del(NULL, audit_info);
   if (rc != 0)
 @@ -377,7 +377,7 @@ void smk_unlbl_ambient(char *oldambient)
   struct netlbl_audit audit_info;
  
   audit_info.loginuid = audit_get_loginuid(current);
 - audit_info.secid = smack_to_secid(current-security);
 + audit_info.secid = smack_to_secid(current-sec-security);
  
   if (oldambient != NULL) {
   rc = netlbl_cfg_map_del(oldambient, audit_info);


The Smack portions look fine.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 07/37] Security: De-embed task security record from task and use refcounting

[Casey Schaufler]

--- David Howells [EMAIL PROTECTED] wrote:

 Remove the temporarily embedded task security record from task_struct. 
 Instead
 it is made to dangle from the task_struct::sec and task_struct::act_as
 pointers
 with references counted for each.
 
 ...
 
 The LSM hooks for dealing with task security are modified to deal with the
 task
 security struct directly rather than going via the task_struct as appopriate.
 
 ...

 diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
 index a49d94f..dbce607 100644
 --- a/security/smack/smack_lsm.c
 +++ b/security/smack/smack_lsm.c
 @@ -957,9 +957,22 @@ static int smack_task_alloc_security(struct task_struct
 *tsk)
   * points to an immutable list. The blobs never go away.
   * There is no leak here.
   */
 -static void smack_task_free_security(struct task_struct *task)
 +static void smack_task_free_security(struct task_security *sec)
  {
 - task-sec-security = NULL;
 + sec-security = NULL;
 +}
 +
 +/**
 + * task_dup_security - Duplicate task security
 + * @p points to the task_security struct that has been copied
 + *
 + * Duplicate the security structure currently attached to the p-security
 field
 + * and attach back to p-security (the pointer itself was copied, so there's
 + * nothing to be done here).
 + */
 +static int smack_task_dup_security(struct task_security *sec)
 +{
 + return 0;
  }

Thank you for adding this hook. The comment is helpful.
  
  /**
 @@ -2276,17 +2289,17 @@ static int smack_inet_conn_request(struct sock *sk,
 struct sk_buff *skb,
  /**
   * smack_key_alloc - Set the key security blob
   * @key: object
 - * @tsk: the task associated with the key
 + * @context: the task security associated with the key
   * @flags: unused
   *
   * No allocation required
   *
   * Returns 0
   */
 -static int smack_key_alloc(struct key *key, struct task_struct *tsk,
 +static int smack_key_alloc(struct key *key, struct task_security *context,
  unsigned long flags)
  {
 - key-security = tsk-act_as-security;
 + key-security = context-security;
   return 0;
  }
  
 @@ -2304,14 +2317,14 @@ static void smack_key_free(struct key *key)
  /*
   * smack_key_permission - Smack access on a key
   * @key_ref: gets to the object
 - * @context: task involved
 + * @context: task security involved
   * @perm: unused
   *
   * Return 0 if the task has read and write to the object,
   * an error code otherwise
   */
  static int smack_key_permission(key_ref_t key_ref,
 - struct task_struct *context, key_perm_t perm)
 + struct task_security *context, key_perm_t perm)
  {
   struct key *keyp;
  
 @@ -2327,10 +2340,10 @@ static int smack_key_permission(key_ref_t key_ref,
   /*
* This should not occur
*/
 - if (context-act_as-security == NULL)
 + if (context-security == NULL)
   return -EACCES;
  
 - return smk_access(context-act_as-security, keyp-security,
 + return smk_access(context-security, keyp-security,
 MAY_READWRITE);
  }
  #endif /* CONFIG_KEYS */
 @@ -2430,6 +2443,7 @@ static struct security_operations smack_ops = {
  
   .task_alloc_security =  smack_task_alloc_security,
   .task_free_security =   smack_task_free_security,
 + .task_dup_security =smack_task_dup_security,
   .task_post_setuid = cap_task_post_setuid,
   .task_setpgid = smack_task_setpgid,
   .task_getpgid = smack_task_getpgid,

No objections from the Smack side. Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 09/37] Security: Allow kernel services to override LSM settings for task actions

[Casey Schaufler]

--- David Howells [EMAIL PROTECTED] 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.
 
 This patch provides two LSM hooks for modifying a task security record:
 
  (*) security_kernel_act_as() which allows modification of the security datum
  with which a task acts on other objects (most notably files).
 
  (*) security_create_files_as() which allows modification of the security
  datum that is used to initialise the security data on a file that a task
  creates.
 
 ...

 --- a/security/smack/smack_lsm.c
 +++ b/security/smack/smack_lsm.c
 @@ -976,6 +976,36 @@ static int smack_task_dup_security(struct task_security
 *sec)
  }
  
  /**
 + * smack_task_kernel_act_as - Set the subjective context in a security
 record
 + * @p points to the task that nominated @secid.
 + * @sec points to the task security record to be modified.
 + * @secid specifies the security ID to be set
 + *
 + * Set the security data for a kernel service.
 + */
 +static int smack_task_kernel_act_as(struct task_struct *p,
 + struct task_security *sec, u32 secid)
 +{
 + return -ENOTSUPP;
 +}
 +
 +/**
 + * smack_task_create_files_as - Set the file creation label in a security
 record
 + * @p points to the task that nominated @inode.
 + * @sec points to the task security record to be modified.
 + * @inode points to the inode to use as a reference.
 + *
 + * Set the file creation context in a security record to the same as the
 + * objective context of the specified inode
 + */
 +static int smack_task_create_files_as(struct task_struct *p,
 +   struct task_security *sec,
 +   struct inode *inode)
 +{
 + return -ENOTSUPP;
 +}

Hum. ENOTSUPP is not not very satisfying, is it? I will have to
think on this a bit.

 +
 +/**
   * smack_task_setpgid - Smack check on setting pgid
   * @p: the task object
   * @pgid: unused
 @@ -2444,6 +2474,8 @@ static struct security_operations smack_ops = {
   .task_alloc_security =  smack_task_alloc_security,
   .task_free_security =   smack_task_free_security,
   .task_dup_security =smack_task_dup_security,
 + .task_kernel_act_as =   smack_task_kernel_act_as,
 + .task_create_files_as = smack_task_create_files_as,
   .task_post_setuid = cap_task_post_setuid,
   .task_setpgid = smack_task_setpgid,
   .task_getpgid = smack_task_getpgid,

Except for the fact that the hooks don't do anything this
looks fine. I'm not sure that I would want these hooks to
do anything, it requires additional thought to determine if
there is a good behavior for them.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] (linus git 02/19/08) Smack update for file capabilities

[Casey Schaufler]

--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Casey Schaufler ([EMAIL PROTECTED]):
  From: Casey Schaufler [EMAIL PROTECTED]
 
  Update the Smack LSM to allow the registration of the capability
  module as a secondary LSM. Integrate the new hooks required for
  file based capabilities.
 
 Hi Casey,
 
 to help people keep their mailboxes straight it'd be good to have a
 changelog here pointing out that you addressed Stephen's point.

Thanks for the reminder.

 Looks good to me.  It's too bad the logic has to be quite so convoluted
 between the two, but I'm not sure it can be improved upon...

It's not so bad.

 And thanks Stephen, I well might have missed the issue you pointed out.

Indeed. The careful review is much appreciated.


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] [RFC] Smack update for file capabilities

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

This patch assumes Smack unlabeled outgoing ambient packets - v4
which is one reason it's RFC.

Update the Smack LSM to allow the registration of the capability
module as a secondary LSM. Integrate the new hooks required for
file based capabilities.

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

security/smack/smack_lsm.c |   63 +--
1 file changed, 60 insertions(+), 3 deletions(-)

diff -uprN -X linux-2.6.25-g0216-precap//Documentation/dontdiff 
linux-2.6.25-g0216-precap/security/smack/smack_lsm.c 
linux-2.6.25-g0216/security/smack/smack_lsm.c
--- linux-2.6.25-g0216-precap/security/smack/smack_lsm.c2008-02-18 
10:53:45.0 -0800
+++ linux-2.6.25-g0216/security/smack/smack_lsm.c   2008-02-18 
14:15:25.0 -0800
@@ -584,6 +584,12 @@ static int smack_inode_getattr(struct vf
static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
{
+   int rc;
+
+   rc = cap_inode_setxattr(dentry, name, value, size, flags);
+   if (rc != 0)
+   return rc;
+
if (!capable(CAP_MAC_ADMIN)) {
if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
@@ -658,6 +664,12 @@ static int smack_inode_getxattr(struct d
 */
static int smack_inode_removexattr(struct dentry *dentry, char *name)
{
+   int rc;
+
+   rc = cap_inode_removexattr(dentry, name);
+   if (rc != 0)
+   return rc;
+
if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
return -EPERM;

@@ -1016,7 +1028,12 @@ static void smack_task_getsecid(struct t
 */
static int smack_task_setnice(struct task_struct *p, int nice)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setnice(p, nice);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1028,7 +1045,12 @@ static int smack_task_setnice(struct tas
 */
static int smack_task_setioprio(struct task_struct *p, int ioprio)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setioprio(p, ioprio);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1053,7 +1075,12 @@ static int smack_task_getioprio(struct t
static int smack_task_setscheduler(struct task_struct *p, int policy,
   struct sched_param *lp)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setscheduler(p, policy, lp);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1093,6 +1120,11 @@ static int smack_task_movememory(struct 
static int smack_task_kill(struct task_struct *p, struct siginfo *info,

   int sig, u32 secid)
{
+   int rc;
+
+   rc = cap_task_kill(p, info, sig, secid);
+   if (rc != 0)
+   return rc;
/*
 * Special cases where signals really ought to go through
 * in spite of policy. Stephen Smalley suggests it may
@@ -1778,6 +1810,27 @@ static int smack_ipc_permission(struct k
return smk_curacc(isp, may);
}

+/* module stacking operations */
+
+/**
+ * smack_register_security - stack capability module
+ * @name: module name
+ * @ops: module operations - ignored
+ *
+ * Allow the capability module to register.
+ */
+static int smack_register_security(const char *name,
+  struct security_operations *ops)
+{
+   if (strcmp(name, capability) != 0)
+   return -EINVAL;
+
+   printk(KERN_INFO %s:  Registering secondary module %s\n,
+  __func__, name);
+
+   return 0;
+}
+
/**
 * smack_d_instantiate - Make sure the blob is correct on an inode
 * @opt_dentry: unused
@@ -2412,6 +2465,8 @@ static struct security_operations smack_
.inode_post_setxattr =  smack_inode_post_setxattr,
.inode_getxattr =   smack_inode_getxattr,
.inode_removexattr =smack_inode_removexattr,
+   .inode_need_killpriv =  cap_inode_need_killpriv,
+   .inode_killpriv =   cap_inode_killpriv,
.inode_getsecurity =smack_inode_getsecurity,
.inode_setsecurity =smack_inode_setsecurity,
.inode_listsecurity =   smack_inode_listsecurity,
@@ -2471,6 +2526,8 @@ static struct security_operations smack_
.netlink_send = cap_netlink_send,
.netlink_recv = cap_netlink_recv,

+   .register_security =smack_register_security,
+
.d_instantiate =smack_d_instantiate,

.getprocattr =  smack_getprocattr,

-
To unsubscribe from this list: send the line unsubscribe 
linux-security

[PATCH] (linus git 02/19/08) Smack update for file capabilities

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Update the Smack LSM to allow the registration of the capability
module as a secondary LSM. Integrate the new hooks required for
file based capabilities.

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

security/smack/smack_lsm.c |   87 +--
1 file changed, 74 insertions(+), 13 deletions(-)

diff -uprN -X linux-2.6.25-g0219-precap/Documentation/dontdiff 
linux-2.6.25-g0219-precap/security/smack/smack_lsm.c 
linux-2.6.25-g0219/security/smack/smack_lsm.c
--- linux-2.6.25-g0219-precap/security/smack/smack_lsm.c2008-02-19 
10:15:30.0 -0800
+++ linux-2.6.25-g0219/security/smack/smack_lsm.c   2008-02-19 
09:24:19.0 -0800
@@ -584,14 +584,20 @@ static int smack_inode_getattr(struct vf
static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
{
-   if (!capable(CAP_MAC_ADMIN)) {
-   if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
-   strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
-   strcmp(name, XATTR_NAME_SMACKIPOUT) == 0)
-   return -EPERM;
-   }
+   int rc = 0;
+
+   if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPOUT) == 0) {
+   if (!capable(CAP_MAC_ADMIN))
+   rc = -EPERM;
+   } else
+   rc = cap_inode_setxattr(dentry, name, value, size, flags);
+
+   if (rc == 0)
+   rc = smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);

-   return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
+   return rc;
}

/**
@@ -658,10 +664,20 @@ static int smack_inode_getxattr(struct d
 */
static int smack_inode_removexattr(struct dentry *dentry, char *name)
{
-   if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
-   return -EPERM;
+   int rc = 0;

-   return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
+   if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPOUT) == 0) {
+   if (!capable(CAP_MAC_ADMIN))
+   rc = -EPERM;
+   } else
+   rc = cap_inode_removexattr(dentry, name);
+
+   if (rc == 0)
+   rc = smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
+
+   return rc;
}

/**
@@ -1016,7 +1032,12 @@ static void smack_task_getsecid(struct t
 */
static int smack_task_setnice(struct task_struct *p, int nice)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setnice(p, nice);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1028,7 +1049,12 @@ static int smack_task_setnice(struct tas
 */
static int smack_task_setioprio(struct task_struct *p, int ioprio)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setioprio(p, ioprio);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1053,7 +1079,12 @@ static int smack_task_getioprio(struct t
static int smack_task_setscheduler(struct task_struct *p, int policy,
   struct sched_param *lp)
{
-   return smk_curacc(p-security, MAY_WRITE);
+   int rc;
+
+   rc = cap_task_setscheduler(p, policy, lp);
+   if (rc == 0)
+   rc = smk_curacc(p-security, MAY_WRITE);
+   return rc;
}

/**
@@ -1093,6 +1124,11 @@ static int smack_task_movememory(struct 
static int smack_task_kill(struct task_struct *p, struct siginfo *info,

   int sig, u32 secid)
{
+   int rc;
+
+   rc = cap_task_kill(p, info, sig, secid);
+   if (rc != 0)
+   return rc;
/*
 * Special cases where signals really ought to go through
 * in spite of policy. Stephen Smalley suggests it may
@@ -1778,6 +1814,27 @@ static int smack_ipc_permission(struct k
return smk_curacc(isp, may);
}

+/* module stacking operations */
+
+/**
+ * smack_register_security - stack capability module
+ * @name: module name
+ * @ops: module operations - ignored
+ *
+ * Allow the capability module to register.
+ */
+static int smack_register_security(const char *name,
+  struct security_operations *ops)
+{
+   if (strcmp(name, capability) != 0)
+   return -EINVAL;
+
+   printk(KERN_INFO %s:  Registering secondary module %s\n,
+  __func__, name);
+
+   return 0;
+}
+
/**
 * smack_d_instantiate - Make sure the blob is correct on an inode
 * @opt_dentry: unused
@@ -2412,6 +2469,8 @@ static struct security_operations smack_
.inode_post_setxattr =  smack_inode_post_setxattr,
.inode_getxattr

Re: Possible problem in linux file posix capabilities

[Casey Schaufler]

--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 
 
 Two quick fixes for you right now (apart from the one you've already
 got :)  would be
 
   1. give wireshark cap_kill, by doing something like
 
   capset cap_kill=ep /bin/wireshark
 
   2. compile a kernel with SECURITY_FILE_CAPABILITIES=n
 
 Andrew, this pretty much was bound to happen...  we need to figure out
 what our approach here should be.  My preference is still to allow
 signals when p-uid==current-uid so long as !SECURE_NOROOT.  Then as
 people start using secure_noroot process trees they at least must know
 what they're asking for.
 
 An alternative stance is to accept these things as they come up and try
 to quickly work with the authors of such programs to work around it.  I
 suppose in a security sense that's the superior way :)  But it also
 seems likely to lead to most people choosing option 2 above and not
 bothering to fix the problem.

I probably just missed it when it went by, but do you have some
test cases for file capabilities lying about that I might use?

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH net-2.6.25] Add packet filtering based on process's security context.

[Casey Schaufler]

--- Tetsuo Handa [EMAIL PROTECTED] wrote:

 ...
 
 Currently, there is no way to directly map security context from incoming
 packet to user process. This is because the creator or owner of a socket is
 not always the receiver of an incoming packet. The userland process who
 receives the incoming packet is not known until a process calls
 sys_recvmsg().
 So, I want to add a LSM hook to give a security module a chance to control
 after the recipient of the incoming packet is known.

Do you have a real situation where two user processes with different
security contexts share a socket? How do you get into that situation,
and is it appropriate to have that situation in your security scheme?
Can this occur without using privilege?


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] (2.6.24-rc8-mm1) -mm Smack socket label setting fix

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Correct the checks in smack_inode_setxattr to include the
socket labeling attributes. Simplify and correct
smack_sock_graft, while the values it was setting were
safe they were not correct and the job was not being
done efficiently. smack_inode_setsecurity wasn't
invoking the required netlabel function in the case
where smk_ipout was set. It does now, but that change
required the hook to be moved in the file. This
movement accounts for the bulk of the patch.


Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

 security/smack/smack.h |2
 security/smack/smack_lsm.c |  136 ---
 2 files changed, 67 insertions(+), 71 deletions(-)

diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc8-mm1-base/security/smack/smack.h 
linux-2.6.24-rc8-mm1-smack/security/smack/smack.h
--- linux-2.6.24-rc8-mm1-base/security/smack/smack.h2008-01-18 
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack.h   2008-01-18 
15:09:43.0 -0800
@@ -130,6 +130,8 @@ struct smack_known {
 #define XATTR_SMACK_IPIN   SMACK64IPIN
 #define XATTR_SMACK_IPOUT  SMACK64IPOUT
 #define XATTR_NAME_SMACK   XATTR_SECURITY_PREFIX XATTR_SMACK_SUFFIX
+#define XATTR_NAME_SMACKIPIN   XATTR_SECURITY_PREFIX XATTR_SMACK_IPIN
+#define XATTR_NAME_SMACKIPOUT  XATTR_SECURITY_PREFIX XATTR_SMACK_IPOUT
 
 /*
  * smackfs macic number
diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c 
linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c2008-01-18 
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c   2008-01-18 
15:30:59.0 -0800
@@ -584,8 +584,12 @@ static int smack_inode_getattr(struct vf
 static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
 {
-   if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
+   if (!capable(CAP_MAC_ADMIN)) {
+   if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPOUT) == 0)
return -EPERM;
+   }
 
return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
 }
@@ -718,57 +722,6 @@ static int smack_inode_getsecurity(const
return rc;
 }
 
-/**
- * smack_inode_setsecurity - set smack xattrs
- * @inode: the object
- * @name: attribute name
- * @value: attribute value
- * @size: size of the attribute
- * @flags: unused
- *
- * Sets the named attribute in the appropriate blob
- *
- * Returns 0 on success, or an error code
- */
-static int smack_inode_setsecurity(struct inode *inode, const char *name,
-  const void *value, size_t size, int flags)
-{
-   char *sp;
-   struct inode_smack *nsp = inode-i_security;
-   struct socket_smack *ssp;
-   struct socket *sock;
-
-   if (value == NULL || size  SMK_LABELLEN)
-   return -EACCES;
-
-   sp = smk_import(value, size);
-   if (sp == NULL)
-   return -EINVAL;
-
-   if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
-   nsp-smk_inode = sp;
-   return 0;
-   }
-   /*
-* The rest of the Smack xattrs are only on sockets.
-*/
-   if (inode-i_sb-s_magic != SOCKFS_MAGIC)
-   return -EOPNOTSUPP;
-
-   sock = SOCKET_I(inode);
-   if (sock == NULL)
-   return -EOPNOTSUPP;
-
-   ssp = sock-sk-sk_security;
-
-   if (strcmp(name, XATTR_SMACK_IPIN) == 0)
-   ssp-smk_in = sp;
-   else if (strcmp(name, XATTR_SMACK_IPOUT) == 0)
-   ssp-smk_out = sp;
-   else
-   return -EOPNOTSUPP;
-   return 0;
-}
 
 /**
  * smack_inode_listsecurity - list the Smack attributes
@@ -1341,6 +1294,60 @@ static int smack_netlabel(struct sock *s
 }
 
 /**
+ * smack_inode_setsecurity - set smack xattrs
+ * @inode: the object
+ * @name: attribute name
+ * @value: attribute value
+ * @size: size of the attribute
+ * @flags: unused
+ *
+ * Sets the named attribute in the appropriate blob
+ *
+ * Returns 0 on success, or an error code
+ */
+static int smack_inode_setsecurity(struct inode *inode, const char *name,
+  const void *value, size_t size, int flags)
+{
+   char *sp;
+   struct inode_smack *nsp = inode-i_security;
+   struct socket_smack *ssp;
+   struct socket *sock;
+
+   if (value == NULL || size  SMK_LABELLEN)
+   return -EACCES;
+
+   sp = smk_import(value, size);
+   if (sp == NULL)
+   return -EINVAL;
+
+   if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
+   nsp-smk_inode = sp;
+   return 0

[PATCH] (2.6.24-rc8-mm1) -mm v2 Smack socket label setting fix

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Correct the checks in smack_inode_setxattr to include the
socket labeling attributes. Simplify and correct
smack_sock_graft, while the values it was setting were
safe they were not correct and the job was not being
done efficiently. smack_inode_setsecurity wasn't
invoking the required netlabel function in the case
where smk_ipout was set. It does now, but that change
required the hook to be moved in the file. This
movement accounts for the bulk of the patch.


Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

This version corrects an indentation error in the previous patch.

 security/smack/smack.h |2
 security/smack/smack_lsm.c |  136 ---
 2 files changed, 67 insertions(+), 71 deletions(-)

diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc8-mm1-base/security/smack/smack.h 
linux-2.6.24-rc8-mm1-smack/security/smack/smack.h
--- linux-2.6.24-rc8-mm1-base/security/smack/smack.h2008-01-18 
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack.h   2008-01-18 
15:09:43.0 -0800
@@ -130,6 +130,8 @@ struct smack_known {
 #define XATTR_SMACK_IPIN   SMACK64IPIN
 #define XATTR_SMACK_IPOUT  SMACK64IPOUT
 #define XATTR_NAME_SMACK   XATTR_SECURITY_PREFIX XATTR_SMACK_SUFFIX
+#define XATTR_NAME_SMACKIPIN   XATTR_SECURITY_PREFIX XATTR_SMACK_IPIN
+#define XATTR_NAME_SMACKIPOUT  XATTR_SECURITY_PREFIX XATTR_SMACK_IPOUT
 
 /*
  * smackfs macic number
diff -uprN -X linux-2.6.24-rc8-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c 
linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc8-mm1-base/security/smack/smack_lsm.c2008-01-18 
14:12:26.0 -0800
+++ linux-2.6.24-rc8-mm1-smack/security/smack/smack_lsm.c   2008-01-18 
20:22:19.0 -0800
@@ -584,8 +584,12 @@ static int smack_inode_getattr(struct vf
 static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
 {
-   if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
-   return -EPERM;
+   if (!capable(CAP_MAC_ADMIN)) {
+   if (strcmp(name, XATTR_NAME_SMACK) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPIN) == 0 ||
+   strcmp(name, XATTR_NAME_SMACKIPOUT) == 0)
+   return -EPERM;
+   }
 
return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
 }
@@ -718,57 +722,6 @@ static int smack_inode_getsecurity(const
return rc;
 }
 
-/**
- * smack_inode_setsecurity - set smack xattrs
- * @inode: the object
- * @name: attribute name
- * @value: attribute value
- * @size: size of the attribute
- * @flags: unused
- *
- * Sets the named attribute in the appropriate blob
- *
- * Returns 0 on success, or an error code
- */
-static int smack_inode_setsecurity(struct inode *inode, const char *name,
-  const void *value, size_t size, int flags)
-{
-   char *sp;
-   struct inode_smack *nsp = inode-i_security;
-   struct socket_smack *ssp;
-   struct socket *sock;
-
-   if (value == NULL || size  SMK_LABELLEN)
-   return -EACCES;
-
-   sp = smk_import(value, size);
-   if (sp == NULL)
-   return -EINVAL;
-
-   if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
-   nsp-smk_inode = sp;
-   return 0;
-   }
-   /*
-* The rest of the Smack xattrs are only on sockets.
-*/
-   if (inode-i_sb-s_magic != SOCKFS_MAGIC)
-   return -EOPNOTSUPP;
-
-   sock = SOCKET_I(inode);
-   if (sock == NULL)
-   return -EOPNOTSUPP;
-
-   ssp = sock-sk-sk_security;
-
-   if (strcmp(name, XATTR_SMACK_IPIN) == 0)
-   ssp-smk_in = sp;
-   else if (strcmp(name, XATTR_SMACK_IPOUT) == 0)
-   ssp-smk_out = sp;
-   else
-   return -EOPNOTSUPP;
-   return 0;
-}
 
 /**
  * smack_inode_listsecurity - list the Smack attributes
@@ -1341,6 +1294,60 @@ static int smack_netlabel(struct sock *s
 }
 
 /**
+ * smack_inode_setsecurity - set smack xattrs
+ * @inode: the object
+ * @name: attribute name
+ * @value: attribute value
+ * @size: size of the attribute
+ * @flags: unused
+ *
+ * Sets the named attribute in the appropriate blob
+ *
+ * Returns 0 on success, or an error code
+ */
+static int smack_inode_setsecurity(struct inode *inode, const char *name,
+  const void *value, size_t size, int flags)
+{
+   char *sp;
+   struct inode_smack *nsp = inode-i_security;
+   struct socket_smack *ssp;
+   struct socket *sock;
+
+   if (value == NULL || size  SMK_LABELLEN)
+   return -EACCES;
+
+   sp = smk_import(value, size);
+   if (sp == NULL)
+   return -EINVAL;
+
+   if (strcmp(name, XATTR_SMACK_SUFFIX) == 0

Re: [PATCH 08/26] Add a secctx_to_secid() LSM hook to go along with the existing

[Casey Schaufler]

--- Paul Moore [EMAIL PROTECTED] wrote:

 On Tuesday 15 January 2008 8:05:27 pm James Morris wrote:
  On Tue, 15 Jan 2008, David Howells wrote:
   secid_to_secctx() LSM hook.  This patch also includes the SELinux
   implementation for this hook.
  
   Signed-off-by: Paul Moore [EMAIL PROTECTED]
   Acked-by: Stephen Smalley [EMAIL PROTECTED]
 
  This is useful in its own right, and I would like to push it upstream for
  2.6.24 unless there are any objections.
 
 Isn't it a bit late in 2.6.24 to add new functionality, especially when there
 
 isn't an in-tree user for it in 2.6.24?
 
 You are right, there are several users of this function currently under 
 development but I'm pretty sure all of them are targeting 2.6.25 or greater. 
 
 With that in mind, I think the prudent thing to is to wait and push this 
 upstream for 2.6.25.

I concur with Paul. I had to delete the message I was composing because
it said exactly the same thing.

I do think that we need to put some thought into what a secid
really is and what a secctx ought to look like what with multiple
user cropping up for them. To date audit is the only out-of-LSM
user of the secctx, and assumes it's a printable text string, but
if cacheing is going to be using it as well we're approaching the
secctx being a general interface, and hence a part of the LSM
proper. Probably makes sense to include something in the LSM
documentation. With luck, someone who spells better than I will
beat me to it, but such an update is on my todo list.




Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] security: remove security_sb_post_mountroot hook

[Casey Schaufler]

--- H. Peter Anvin [EMAIL PROTECTED] wrote:

 The security_sb_post_mountroot() hook is long-since obsolete, and is
 fundamentally broken: it is never invoked if someone uses initramfs.
 This is particularly damaging, because the existence of this hook has
 been used as motivation for not using initramfs.
 
 Stephen Smalley confirmed on 2007-07-19 that this hook was originally
 used by SELinux but can now be safely removed:
 
  http://marc.info/?l=linux-kernelm=118485683612916w=2
 
 Cc: Stephen Smalley [EMAIL PROTECTED]
 Cc: James Morris [EMAIL PROTECTED]
 Cc: Eric Paris [EMAIL PROTECTED]
 Cc: Chris Wright [EMAIL PROTECTED]
 Signed-off-by: H. Peter Anvin [EMAIL PROTECTED]

It is also the case that Smack does not use this hook.
It can be removed as far as I'm concerned.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: POSIX file capabilities for directories

[Casey Schaufler]

--- Jan Engelhardt [EMAIL PROTECTED] wrote:

 
 On Dec 26 2007 16:29, Andrew Morgan wrote:
  
  I'm assuming it's unintended - or rather it's harmless but has no use -
  but will let Andrew respond since he may have some cool idea i haven't
  thought of.
 
 This is not intended behavior. It should be fixed (aka such support
 removed). Capabilities should only be available on executable files -
 not directories, symlinks or anything else...
 
 What about defining Windows-style access control, e.g. splitting up
 the +w bit into append (create new files) and delete files?

Please, no.

POSIX capabilities are only meaningfull on files. They are
are and should be ignored on any other sort of object. The
simple name/value pair model of xattrs could get uglified
by working too hard at making sure that only good names get
on objects.

If you want to use an attribute to differentiate between
append and delete files, pick a different name and implement
an LSM to enforce it.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v8 05/18] LSM: Add secctx_to_secid() LSM hook

[Casey Schaufler]

--- Stephen Smalley [EMAIL PROTECTED] wrote:

 On Fri, 2007-12-14 at 16:50 -0500, Paul Moore wrote:
  Add a secctx_to_secid() LSM hook to go along with the existing
  secid_to_secctx() LSM hook.  This patch also includes the SELinux
  implementation for this hook.
 
 Acked-by:  Stephen Smalley [EMAIL PROTECTED]
 
 This one can go up anytime, as we have other people wanting such a hook
 too.

I can't provide any justifications why it shouldn't go in,
and there will no doubt be places where the continued use of
secids will require it going forward.

 Or alternatively we need to rationalize the entire selinux/exports
 interface with these hooks as used by the networking and audit
 subsystems, as that issue will be coming up anyway for other LSMs.

Yeah. Smack is taking the pragmatic path, assuming that secid and
secctx will be around at least until pigs nest in trees. You left
out the USB subsystems's use of secid's, which may be the least
savory of all.

 One thing to note is that some of these interfaces treat the context as
 an opaque byte array of a given length, while other ones depend on the
 context to be a NUL-terminated string (e.g. audit).

Smack and SELiunx always provide a NUL-terminated string. I would
be in favor of defining a secctx as the textual representation of a
security blob. If we don't, we'll need to define a third thing that
is the text representation for audit before it's possible to convert
audit from SELinux calls to LSM calls. Converting audit to use LSM
calls will be mostly straitforward if the secctx can be assumed to
be a string.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- 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-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- Stephen Smalley [EMAIL PROTECTED] wrote:

 
  I am much more concerned with the interfaces used to pass the
  information into the kernel. I would expect that to be LSM
  independent, not a call into libselinux that resolves into a
  selinuxfs operation, or it's netlink equivilant. It would be
  unfortunate if the userland/kernel interface became an obstacle
  to cachefiles being adopted.
 
 That wasn't the issue.  The interface to the cachefiles module would
 just consist of cachefilesd writing a string label to some pseudo file
 tell cachefiles what label to apply as the acting label for operations
 performed by cachefiles.  Which isn't SELinux-specific at all.

Calm down. Just checking.

 David was asking though how cachefilesd (the userspace agent) would
 obtain such a label to use.  And that may very well be LSM-specific, and
 as there is no LSM userspace API, it makes sense for him to invoke a
 libselinux function at present.  If a liblsm is later created and
 provides a common front-end API (internally dlopen'ing the right shared
 library based on some configuration, whether libselinux or libsmack or
 whatever), then cachefilesd can instead call the liblsm interface, but
 that doesn't exist today.

I am certainly not in favor of adding such complexity.
I suggest that cachefilesd get the context it wants using
whatever scheme works. I think there should be a cachefiles
specific (LSM independent) scheme for getting it into the
kernel, and a LSM hooks for setting it, if that's what he
really wants to do.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- David Howells [EMAIL PROTECTED] wrote:

...
 
 How about I just stick the context in /etc/cachefilesd.conf as a textual
 configuration item and have the daemon pass that as a string to the
 cachefiles
 kernel module, which can then ask LSM if it's valid to set this context as an
 override, given the daemon's own security context?  That seems entirely
 reasonable to me.

Works for Smack. I can't say definitively, but I think it will
work for SELinux. Beyond that and we're into the fuzzy bit of the
LSM.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- Stephen Smalley [EMAIL PROTECTED] wrote:

 On Mon, 2007-12-10 at 21:08 +, David Howells wrote:
  Stephen Smalley [EMAIL PROTECTED] wrote:
  
   Otherwise, only other issue I have with this interface is it won't
   generalize to dealing with nfsd, where we want to set the acting context
   to a context we obtain from or determine based upon the client.
  
  Are you speaking of security_kernel_act_as() and security_create_files_as()
  specifically?  Or the task_struct::act_as override pointer in general?
 
 security_kernel_act_as()
 
  I don't really know how nfsd wants to obtain and set its LSM context, so
 it's
  a bit difficult for me to make something that works for nfsd as well as
  cachefiles.
 
 It would get a context from the client or from a local configuration
 that would map security-unaware clients to a default context, and then
 want to assume that context for the particular operation.  No transition
 involved.

I would expect that the operation would be more sophisticated
than that. You certainly aren't going to use what comes from
the other side without any processing, and I expect you'll have
some sort of operation on anything you pull from a config file
before you actually apply it.

   Why can't cachefilesd just push a context into the kernel and pass that
   into the hook as the acting context,
  
  How does cachefilesd come up with such a context?  Grab it from
  /etc/cachefilesd.conf?
 
 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.  Has to be done that way so that it
 can be set differently for different policy types (strict, targeted,
 mls).

Unless you've got an LSM other than SELinux, of course. If
cachefilesd is going to be responsible for maintaining this
magic context there needs to be an LSM interface for it, not
just an SELinux interface.

 Naturally, cachefiles (the kernel module) would invoke a security hook
 to check whether the daemon is allowed to set the specified context.
 
  I use to do that, but someone objected...  Possibly Karl MacMillan.
 
 Yes, but I think I disagreed then too.
 
   and then nfsd can do likewise using the context provided by the client or
   obtained locally from exports for ordinary clients?  Avoids the
 transition
   SID computation altogether within the kernel and makes this more generic.
  
  I seem to remember that I was told that it should be done this way,
 possibly
  by Karl MacMillan, but I don't remember exactly.
  
  Now it's configured by cachefilesd.te:
  
  type_transition cachefilesd_t kernel_t : process cachefiles_kernel_t;
 
 It doesn't fit with how other users of security_kernel_act_as() will
 likely want to work (they will want to just set the context to a
 specified value, whether one obtained from the client or from some local
 source), nor with how type transitions normally work (exec, with the
 program type as the second type field).  I think it will just cause
 confusion and subtle breakage.

I think that I agree with Stephen, although I could be mirely confused.
That happens to me when interfaces are described in SELinux terms. I
still don't care much for multiple contexts, and I don't have a good
grasp of how you'll deal with Smack, or any LSM other than SELinux.
Just as Stephen mentions, I also don't see the generality that a change
of this magnitude really ought to provide.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]

[Casey Schaufler]

--- David Howells [EMAIL PROTECTED] wrote:

 Stephen Smalley [EMAIL PROTECTED] wrote:
 
  From a config file whose pathname would be provided by libselinux (ala
  the way in which dbusd imports contexts), or directly as a context
  returned by a libselinux function.
 
 That sounds too SELinux specific.  How do I do it so that it works for any
 LSM?
 
 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.

Linking against libselinux is not now, nor will it ever be, a viable
option. There's just too much sophistication contained in libselinux
for us simple folk to deal with.

   I use to do that, but someone objected...  Possibly Karl MacMillan.
  
  Yes, but I think I disagreed then too.
 
 So, who's right?

Me! (smiley inserted here, for those in need)

  It doesn't fit with how other users of security_kernel_act_as() will
  likely want to work (they will want to just set the context to a
  specified value, whether one obtained from the client or from some local
  source), nor with how type transitions normally work (exec, with the
  program type as the second type field).  I think it will just cause
  confusion and subtle breakage.
 
 It's causing me lots of confusion as it is.  I have been / am being told by
 different people to do different things just in dealing with SELinux, and
 various people are raising extra requirements or restrictions beyond that.
 There doesn't seem to be a consensus.
 
 It sounds like the best option is just to have the kernel nick the userspace
 daemon's security context and use that as is, and junk all the restrictions
 on
 what the daemon can do so that the kernel isn't too restricted.

That would be consistant with the (perhaps archaic now) behavior
of nfsd on Unix, which did nothing but lend it's credential to the
underlying kernel code. I think it's a rational approach, although I
expect that in may have troubles under SELinux.


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] (2.6.24-rc4-mm1) -mm Smack getpeercred_stream fix for SO_PEERSEC and TCP

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Collect the Smack label of the other end on connection so that
getsockopt(..., SO_PEERSEC, ...) can report it. This is done
in smack_inet_conn_request(). Report the correct value in
smack_socket_getpeersec_stream(). Initialize the smk_packet
field in the socket blob. Comment on the purpose of smk_packet
in the header file and remove the unused smk_depth field from
the blob.

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

 security/smack/smack.h |7 +++
 security/smack/smack_lsm.c |   14 +++---
 2 files changed, 14 insertions(+), 7 deletions(-)

diff -uprN -X linux-2.6.24-rc4-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc4-mm1-base/security/smack/smack.h 
linux-2.6.24-rc4-mm1-smack/security/smack/smack.h
--- linux-2.6.24-rc4-mm1-base/security/smack/smack.h2007-12-04 
19:20:59.0 -0800
+++ linux-2.6.24-rc4-mm1-smack/security/smack/smack.h   2007-12-07 
09:25:16.0 -0800
@@ -44,10 +44,9 @@ struct superblock_smack {
 };
 
 struct socket_smack {
-   char*smk_out;   /* outbound label */
-   char*smk_in;/* inbound label */
-   charsmk_packet[SMK_LABELLEN];
-   int smk_depth;
+   char*smk_out;   /* outbound label */
+   char*smk_in;/* inbound label */
+   charsmk_packet[SMK_LABELLEN];   /* TCP peer label */
 };
 
 /*
diff -uprN -X linux-2.6.24-rc4-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc4-mm1-base/security/smack/smack_lsm.c 
linux-2.6.24-rc4-mm1-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc4-mm1-base/security/smack/smack_lsm.c2007-12-04 
19:20:59.0 -0800
+++ linux-2.6.24-rc4-mm1-smack/security/smack/smack_lsm.c   2007-12-07 
11:10:58.0 -0800
@@ -1232,6 +1232,7 @@ static int smack_sk_alloc_security(struc
 
ssp-smk_in = csp;
ssp-smk_out = csp;
+   ssp-smk_packet[0] = '\0';
 
sk-sk_security = ssp;
 
@@ -2115,11 +2116,11 @@ static int smack_socket_getpeersec_strea
int rc = 0;
 
ssp = sock-sk-sk_security;
-   slen = strlen(ssp-smk_out);
+   slen = strlen(ssp-smk_packet) + 1;
 
if (slen  len)
rc = -ERANGE;
-   else if (copy_to_user(optval, ssp-smk_out, slen) != 0)
+   else if (copy_to_user(optval, ssp-smk_packet, slen) != 0)
rc = -EFAULT;
 
if (put_user(slen, optlen) != 0)
@@ -2251,8 +2252,15 @@ static int smack_inet_conn_request(struc
/*
 * Receiving a packet requires that the other end
 * be able to write here. Read access is not required.
+*
+* If the request is successful save the peer's label
+* so that SO_PEERCRED can report it.
 */
-   return smk_access(smack, ssp-smk_in, MAY_WRITE);
+   rc = smk_access(smack, ssp-smk_in, MAY_WRITE);
+   if (rc == 0)
+   strncpy(ssp-smk_packet, smack, SMK_MAXLEN);
+
+   return rc;
 }
 
 /*

-
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

Re: [PATCH 4/7] KEYS: Add keyctl function to get a security label

[Casey Schaufler]

 keyctl_assume_authority((key_serial_t) arg2);
  
 + case KEYCTL_GET_SECURITY:
 + return keyctl_get_security((key_serial_t) arg2,
 +(char *) arg3,
 +(size_t) arg4);
 +
   default:
   return -EOPNOTSUPP;
   }
 diff --git a/security/security.c b/security/security.c
 index 0e1f1f1..16213e3 100644
 --- a/security/security.c
 +++ b/security/security.c
 @@ -1079,4 +1079,9 @@ int security_key_permission(key_ref_t key_ref,
   return security_ops-key_permission(key_ref, context, perm);
  }
  
 +int security_key_getsecurity(struct key *key, char **_buffer)
 +{
 + return security_ops-key_getsecurity(key, _buffer);
 +}
 +
  #endif   /* CONFIG_KEYS */
 diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
 index 9f3124b..bd4cfab 100644
 --- a/security/selinux/hooks.c
 +++ b/security/selinux/hooks.c
 @@ -4768,6 +4768,20 @@ static int selinux_key_permission(key_ref_t key_ref,
   SECCLASS_KEY, perm, NULL);
  }
  
 +static int selinux_key_getsecurity(struct key *key, char **_buffer)
 +{
 + struct key_security_struct *ksec = key-security;
 + char *context = NULL;
 + unsigned len;
 + int rc;
 +
 + rc = security_sid_to_context(ksec-sid, context, len);
 + if (!rc)
 + rc = len;
 + *_buffer = context;
 + return rc;
 +}
 +
  #endif
  
  static struct security_operations selinux_ops = {
 @@ -4943,9 +4957,10 @@ static struct security_operations selinux_ops = {
  #endif
  
  #ifdef CONFIG_KEYS
 - .key_alloc =selinux_key_alloc,
 - .key_free = selinux_key_free,
 - .key_permission =   selinux_key_permission,
 + .key_alloc =selinux_key_alloc,
 + .key_free = selinux_key_free,
 + .key_permission =   selinux_key_permission,
 + .key_getsecurity =  selinux_key_getsecurity,
  #endif
  };
  
 
 
 


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 4/7] KEYS: Add keyctl function to get a security label

[Casey Schaufler]

--- David Howells [EMAIL PROTECTED] wrote:

 Stephen Smalley [EMAIL PROTECTED] wrote:
 
  inode_getsecurity and getprocattr directly return the strings.
  Admittedly, the whole interface could be cleaned up and made far more
  consistent, but I don't think he necessarily has to go through the
  getsecid + secid_to_secctx sequence if he only wants the secctx.
 
 It's what Daniel Walsh wanted.

Name dropper. And we don't have a convention, really. So go ahead
with key_getsecurity or key_getsecctx, as you choose. At some point
we should either change inode_getsecurity to inode_getsecctx or
secid_to_secctx to secid_to_security. Not the problem of the day.



Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] (2.6.24-rc3-mm2) -mm Smack mutex, capability, pointers, and spelling cleanup

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Addresses comments from akpm.

Clean out unnecessary mutex initializations for Smack list locks.
Once this is done, there is no need for them to be shared among
multiple files, so pull them out of the header file and put them
in the files where they belong. Make them static, too.

Pull unnecessary locking from smack_inode_setsecurity, it used
to be required when the assignment was not guaranteed to be a
scalar value but isn't now.

Change uses of __capable(current,...) to capable(...).

Take out an inappropriate cast. Use container_of() instead
of doing the same calculation by hand.

Fix comment spelling errors.

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

 security/smack/smack.h|3 --
 security/smack/smack_access.c |3 ++
 security/smack/smack_lsm.c|   34 +---
 security/smack/smackfs.c  |6 +
 4 files changed, 19 insertions(+), 27 deletions(-)

diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm2-base/security/smack/smack_access.c 
linux-2.6.24-rc3-mm2-smack/security/smack/smack_access.c
--- linux-2.6.24-rc3-mm2-base/security/smack/smack_access.c 2007-11-27 
16:47:05.0 -0800
+++ linux-2.6.24-rc3-mm2-smack/security/smack/smack_access.c2007-12-03 
20:59:51.0 -0800
@@ -58,6 +58,7 @@ struct smack_known smack_known_invalid =
 };
 
 struct smack_known *smack_known = smack_known_invalid;
+
 /*
  * The initial value needs to be bigger than any of the
  * known values above.
@@ -173,6 +174,8 @@ int smk_curacc(char *obj_label, u32 mode
return rc;
 }
 
+static DEFINE_MUTEX(smack_known_lock);
+
 /**
  * smk_import_entry - import a label, return the list entry
  * @string: a text string that might be a Smack label
diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm2-base/security/smack/smackfs.c 
linux-2.6.24-rc3-mm2-smack/security/smack/smackfs.c
--- linux-2.6.24-rc3-mm2-base/security/smack/smackfs.c  2007-11-27 
16:47:05.0 -0800
+++ linux-2.6.24-rc3-mm2-smack/security/smack/smackfs.c 2007-12-03 
20:59:59.0 -0800
@@ -41,6 +41,12 @@ enum smk_inos {
 };
 
 /*
+ * List locks
+ */
+static DEFINE_MUTEX(smack_list_lock);
+static DEFINE_MUTEX(smack_cipso_lock);
+
+/*
  * This is the ambient label for network traffic.
  * If it isn't somehow marked, use this.
  * It can be reset via smackfs/ambient
diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm2-base/security/smack/smack.h 
linux-2.6.24-rc3-mm2-smack/security/smack/smack.h
--- linux-2.6.24-rc3-mm2-base/security/smack/smack.h2007-11-27 
16:47:05.0 -0800
+++ linux-2.6.24-rc3-mm2-smack/security/smack/smack.h   2007-11-28 
11:47:07.0 -0800
@@ -186,7 +186,6 @@ extern int smack_net_nltype;
 extern char *smack_net_ambient;
 
 extern struct smack_known *smack_known;
-extern struct mutex smack_known_lock;
 extern struct smack_known smack_known_floor;
 extern struct smack_known smack_known_hat;
 extern struct smack_known smack_known_huh;
@@ -195,8 +194,6 @@ extern struct smack_known smack_known_st
 extern struct smack_known smack_known_unset;
 
 extern struct smk_list_entry *smack_list;
-extern struct mutex smack_list_lock;
-extern struct mutex smack_cipso_lock;
 
 /*
  * Stricly for CIPSO level manipulation.
diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm2-base/security/smack/smack_lsm.c 
linux-2.6.24-rc3-mm2-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc3-mm2-base/security/smack/smack_lsm.c2007-11-27 
16:47:05.0 -0800
+++ linux-2.6.24-rc3-mm2-smack/security/smack/smack_lsm.c   2007-11-28 
11:46:13.0 -0800
@@ -126,7 +126,7 @@ static int smack_syslog(int type)
if (rc != 0)
return rc;
 
-   if (__capable(current, CAP_MAC_OVERRIDE))
+   if (capable(CAP_MAC_OVERRIDE))
return 0;
 
 if (sp != smack_known_floor.smk_known)
@@ -584,8 +584,7 @@ static int smack_inode_getattr(struct vf
 static int smack_inode_setxattr(struct dentry *dentry, char *name,
void *value, size_t size, int flags)
 {
-   if (strcmp(name, XATTR_NAME_SMACK) == 0 
-   !__capable(current, CAP_MAC_ADMIN))
+   if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
return -EPERM;
 
return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
@@ -655,8 +654,7 @@ static int smack_inode_getxattr(struct d
  */
 static int smack_inode_removexattr(struct dentry *dentry, char *name)
 {
-   if (strcmp(name, XATTR_NAME_SMACK) == 0 
-   !__capable(current, CAP_MAC_ADMIN))
+   if (strcmp(name, XATTR_NAME_SMACK) == 0  !capable(CAP_MAC_ADMIN))
return -EPERM;
 
return smk_curacc(smk_of_inode(dentry-d_inode), MAY_WRITE);
@@ -736,7 +734,7 @@ static int smack_inode_setsecurity(struc

[PATCH] (2.4.26-rc3-mm2) -mm Update CAP_LAST_CAP to reflect CAP_MAC_ADMIN

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

Bump the value of CAP_LAST_CAP to reflect the current last cap value.
It appears that the patch that introduced CAP_LAST_CAP and the patch
that introduced CAP_MAC_ADMIN came in more or less at the same time.

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

 include/linux/capability.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)


diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm2-base/include/linux/capability.h 
linux-2.6.24-rc3-mm2-lastcap/include/linux/capability.h
--- linux-2.6.24-rc3-mm2-base/include/linux/capability.h2007-11-27 
16:47:02.0 -0800
+++ linux-2.6.24-rc3-mm2-lastcap/include/linux/capability.h 2007-11-28 
14:04:57.0 -0800
@@ -315,10 +315,6 @@ typedef struct kernel_cap_struct {
 
 #define CAP_SETFCAP 31
 
-#define CAP_LAST_CAP CAP_SETFCAP
-
-#define cap_valid(x) ((x) = 0  (x) = CAP_LAST_CAP)
-
 /* Override MAC access.
The base kernel enforces no MAC policy.
An LSM may enforce a MAC policy, and if it does and it chooses
@@ -336,6 +332,10 @@ typedef struct kernel_cap_struct {
 
 #define CAP_MAC_ADMIN33
 
+#define CAP_LAST_CAP CAP_MAC_ADMIN
+
+#define cap_valid(x) ((x) = 0  (x) = CAP_LAST_CAP)
+
 /*
  * Bit location of each capability (used by user-space library and kernel)
  */

-
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

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

[Casey Schaufler]

--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Stephen Smalley ([EMAIL PROTECTED]):
  On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote:
   Quoting Crispin Cowan ([EMAIL PROTECTED]):
Just the name sys_hijack makes me concerned.

This post describes a bunch of what, but doesn't tell us about why
we would want this. What is it for?
   
   Please see my response to Casey's email.
   
And I second Casey's concern about careful management of the privilege
required to hijack a process.
   
   Absolutely.  We're definately still in RFC territory.
   
   Note that there are currently several proposed (but no upstream) ways to
   accomplish entering a namespace:
   
 1. bind_ns() is a new pair of syscalls proposed by Cedric.  An
 nsproxy is given an integer id.  The id can be used to enter
 an nsproxy, basically a straight current-nsproxy = target_nsproxy;
   
 2. I had previously posted a patchset on top of the nsproxy
 cgroup which allowed entering a nsproxy through the ns cgroup
 interface.
   
   There are objections to both those patchsets because simply switching a
   task's nsproxy using a syscall or file write in the middle of running a
   binary is quite unsafe.  Eric Biederman had suggested using ptrace or
   something like it to accomplish the goal.
   
   Just using ptrace is however not safe either.  You are inheriting *all*
   of the target's context, so it shouldn't be difficult for a nefarious
   container/vserver admin to trick the host admin into running something
   which gives the container/vserver admin full access to the host.
  
  I don't follow the above - with ptrace, you are controlling a process
  already within the container (hence in theory already limited to its
  container), and it continues to execute within that container.  What's
  the issue there?
 
 Hmm, yeah, I may have overspoken - I'm not good at making up exploits
 but while I see it possible to confuse the host admin by setting bogus
 environment, I guess there may not be an actual exploit.
 
 Still after the fork induced through ptrace, we'll have to execute a
 file out of the hijacked process' namespaces and path (unless we get
 *really* 'exotic').  With hijack, execution continues under the caller's
 control, which I do much prefer.
 
 The remaining advantages of hijack over ptrace (beside using ptrace for
 that is crufty) are
 
   1. not subject to pid wraparound (when doing hijack_cgroup
  or hijack_ns)
   2. ability to enter a namespace which has no active processes
 
 These also highlight selinux issues.  In the case of hijacking an
 empty cgroup, there is no security context (because there is no task) so
 the context of 'current' will be used.  In the case of hijacking a
 populated cgroup, a task is chosen at random to be the hijack source.
 
 So there are two ways to look at deciding which context to use.  Since
 control continues in the original acting process' context, we might
 want the child to continue in its context.  However if the process
 creates any objects in the virtual server, we don't want them
 mislabeled, so we might want the task in the hijacked task's context.

I wouldn't be surprised if you've been over this a dozen times
already, but why hijack an existing process instead of injecting
a new one with completely specified attributes? That way you don't
distinguish between an empty cgroup and a propulated one and you're
not at the mercy of the available hijackees. I know that I would be
much less uncomfortable with that schenario.

 Sigh.  So here's why I thought I'd punt on selinux at least until I had
 a working selinux-enforced container/vserver  :)
 
 -serge
 
 PS: I'm certainly open to the suggestion that the kernel patch in the
 end us as crufty as using ptrace.
 
   That's where the hijack idea came from.  Yes, I called it hijack to make
   sure alarm bells went off :) bc it's definately still worrisome.  But at
   this point I believe it is the safest solution suggested so far.
  
  -- 
  Stephen Smalley
  National Security Agency
  
  -
  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
 -
 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
 
 
 


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] -mm (2.4.26-rc3-mm1) v2 Smack using capabilities 32 and 33

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

This patch takes advantage of the increase in capability bits
to allocate capabilities for Mandatory Access Control. Whereas
Smack was overloading a previously allocated capability it is
now using a pair, one for overriding access control checks and
the other for changes to the MAC configuration.

The two capabilities allocated should be obvious in their intent.
The comments in capability.h are intended to make it clear that
there is no intention that implementations of MAC LSM modules
be any more constrained by the presence of these capabilities
than an implementation of DAC LSM modules are by the analogous
DAC capabilities.


Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

The companion patch for libcap-2.02 is provided as an attachment.
The attachment is not a kernel patch, although it would be easy to
mistake it for one.

Introduces CAP_FS_MASK_B1 and uses it as appropriate. I think that
I found all the places it needs to be used, but don't hesitate to
let me know if I missed something.

Thank you.

 include/linux/capability.h |   24 ++--
 security/smack/smack.h |8 
 security/smack/smack_lsm.c |8 
 security/smack/smackfs.c   |   12 ++--
 4 files changed, 32 insertions(+), 20 deletions(-)

diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm1-base/include/linux/capability.h 
linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
--- linux-2.6.24-rc3-mm1-base/include/linux/capability.h2007-11-22 
01:51:36.0 -0800
+++ linux-2.6.24-rc3-mm1-smack/include/linux/capability.h   2007-11-25 
21:38:34.0 -0800
@@ -314,6 +314,23 @@ typedef struct kernel_cap_struct {
 
 #define CAP_SETFCAP 31
 
+/* Override MAC access.
+   The base kernel enforces no MAC policy.
+   An LSM may enforce a MAC policy, and if it does and it chooses
+   to implement capability based overrides of that policy, this is
+   the capability it should use to do so. */
+
+#define CAP_MAC_OVERRIDE 32
+
+/* Allow MAC configuration or state changes.
+   The base kernel requires no MAC configuration.
+   An LSM may enforce a MAC policy, and if it does and it chooses
+   to implement capability based checks on modifications to that
+   policy or the data required to maintain it, this is the
+   capability it should use to do so. */
+
+#define CAP_MAC_ADMIN33
+
 /*
  * Bit location of each capability (used by user-space library and kernel)
  */
@@ -336,6 +353,8 @@ typedef struct kernel_cap_struct {
| CAP_TO_MASK(CAP_FOWNER)   \
| CAP_TO_MASK(CAP_FSETID))
 
+# define CAP_FS_MASK_B1 (CAP_TO_MASK(CAP_MAC_OVERRIDE))
+
 #if _LINUX_CAPABILITY_U32S != 2
 # error Fix up hand-coded capability macro initializers
 #else /* HAND-CODED capability initializers */
@@ -343,8 +362,9 @@ typedef struct kernel_cap_struct {
 # define CAP_EMPTY_SET{{ 0, 0 }}
 # define CAP_FULL_SET {{ ~0, ~0 }}
 # define CAP_INIT_EFF_SET {{ ~CAP_TO_MASK(CAP_SETPCAP), ~0 }}
-# define CAP_FS_SET   {{ CAP_FS_MASK_B0, 0 }}
-# define CAP_NFSD_SET {{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), 0 }}
+# define CAP_FS_SET   {{ CAP_FS_MASK_B0, CAP_FS_MASK_B1 } }
+# define CAP_NFSD_SET {{ CAP_FS_MASK_B0|CAP_TO_MASK(CAP_SYS_RESOURCE), \
+CAP_FS_MASK_B1 } }
 
 #endif /* _LINUX_CAPABILITY_U32S != 2 */
 
diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff 
linux-2.6.24-rc3-mm1-base/security/smack/smackfs.c 
linux-2.6.24-rc3-mm1-smack/security/smack/smackfs.c
--- linux-2.6.24-rc3-mm1-base/security/smack/smackfs.c  2007-11-22 
01:51:43.0 -0800
+++ linux-2.6.24-rc3-mm1-smack/security/smack/smackfs.c 2007-11-24 
11:29:29.0 -0800
@@ -241,7 +241,7 @@ static ssize_t smk_write_load(struct fil
 * No partial writes.
 * Enough data must be present.
 */
-   if (!capable(CAP_MAC_OVERRIDE))
+   if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (*ppos != 0)
return -EINVAL;
@@ -474,7 +474,7 @@ static ssize_t smk_write_cipso(struct fi
 * No partial writes.
 * Enough data must be present.
 */
-   if (!capable(CAP_MAC_OVERRIDE))
+   if (!capable(CAP_MAC_ADMIN))
return -EPERM;
if (*ppos != 0)
return -EINVAL;
@@ -601,7 +601,7 @@ static ssize_t smk_write_doi(struct file
char temp[80];
int i;
 
-   if (!capable(CAP_MAC_OVERRIDE))
+   if (!capable(CAP_MAC_ADMIN))
return -EPERM;
 
if (count = sizeof(temp) || count == 0)
@@ -666,7 +666,7 @@ static ssize_t smk_write_direct(struct f
char temp[80];
int i;
 
-   if (!capable(CAP_MAC_OVERRIDE))
+   if (!capable(CAP_MAC_ADMIN))
return -EPERM;
 
if (count = sizeof(temp) || count == 0)
@@ -747,7 +747,7 @@ static ssize_t

Re: [PATCH 2/2] hijack: update task_alloc_security

[Casey Schaufler]

/hooks.c
 ===
 --- upstream.orig/security/selinux/hooks.c
 +++ upstream/security/selinux/hooks.c
 @@ -2788,11 +2788,15 @@ static int selinux_task_create(unsigned 
   return task_has_perm(current, current, PROCESS__FORK);
  }
  
 -static int selinux_task_alloc_security(struct task_struct *tsk)
 +static int selinux_task_alloc_security(struct task_struct *tsk,
 +   struct task_struct *hijack_src)
  {
   struct task_security_struct *tsec1, *tsec2;
   int rc;
  
 + if (hijack_src != current)
 + return -EPERM;
 +
   tsec1 = current-security;
  
   rc = task_alloc_security(tsk);
 -
 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
 
 
 


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

[Casey Schaufler]

--- Crispin Cowan [EMAIL PROTECTED] wrote:

 Andrew Morgan wrote:
  Its not so much why you are wrong, as being clear that we're not using a
  generic name and inadvertently limiting ourselves to a SMACK-like model...

 It seems we all agree that it is a bad idea to tie a POSIX Capability to
 one specific LSM model.

I think that's fair.

  It feels to me as if a MAC override capability is, if true to its
  name, extra to the MAC model; any MAC model that needs an 'override' to
  function seems under-specified...

That's the reason we have a privilege model, not just for
MAC, but DAC as well. The Unix/Linux model where administration
and system tasks are performed by normal processes that are
just a little bit special, as opposed to a completely separate
set of interfaces, often makes things look a little contrived.
This is one of the advantages of SELinux, with it's model of
complete specification.

 An interesting observation. This is a core part of why I have always
 found the hierarchical models BLP and Biba to be unsatisfying. These
 systems essentially have one simple fixed policy process label must
 dominate object label to get access, and then you express all the rest
 of your policy by labeling your stuff. It is impossible to manage such
 systems without a MAC_OVERRIDE escape hatch of some kind, because the
 policy is too simple and inflexible, e.g. it does not allow you to
 reclassify anything.

Wll... That's sort of what the mandatory is all about.

   SELinux clearly feels no need for one,

 That's not quite right. More specifically, it already has one in the
 form of unconfined_t. AppArmor has a similar escape hatch in the Ux
 permission. Its not that they don't need one, it is that they already
 have one. They get to have one because they allow you to actually write
 a policy that is more nuanced than process label must dominate object
 label.

That SELinux doesn't require any capabilities is an artifact of
design on that LSM. The whole notion of privilege is somewhat out
of context when your model is to explicitly state how every possible
decision ought to go. That is one important philosophical difference
between SELinux and Smack, with Smack taking a higher level view
on policy and hence privilege.

  and browsing through your SMACK patch, there are many instances where
  this capability is used as an convenience privileged override. However,
  in other situations, it appears as if the capability is required for
  basic SMACK operations to succeed.
 
  My sense is that there is a case to be made for: CAP_MAC_ADMIN and
  CAP_MAC_OVERRIDE here. The former being for cases where SMACK (or
  whatever MAC supports it) requires privilege to perform a privileged MAC
  operation, and the latter for saying OK, I'm without a paddle but need
  one (or words to that effect).

 I don't get the difference. Both seem to permit the process to violate
 the MAC policy. I could make up a meaning for MAC_ADMIN that is
 different from MAC_OVERRIDE in the AppArmor sense, but I don't want to
 :-) and worse, I suspect the distinction would be different for each
 LSM. So let not, and just have one MAC_OVERRIDE capability.

I am pretty close to agreeing with Andrew that a distinction
between allowing a process to change the state of the MAC
configuration (e.g. set file or process MAC labels, add rules)
and violating the rules is in order. SELinux can ignore both,
AppArmor can ignore one, and the upcoming DG/UX port* can ask for
further granularity when they show up.

I will look in this direction and see if I can patches proposed
before the virus in my sinuses knocks me out completely.

Thank you.


*  DG/UX supported over 330 capabilities and is my personal
   poster child for excesses of granularity with regard to
   capabilities. I don't really expect to see a Linux port.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: + smack-version-11c-simplified-mandatory-access-control-kernel.patch added to -mm tree

[Casey Schaufler]

--- Andrew Morgan [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Casey Schaufler wrote:
  In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
  I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
  CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
  unnecessarily ties it to one LSM, and in spite of what some people
  still seem to think, I see more LSMs in the pipeline.
 
 I'd personally not like to see SMACK appear in a capability name. No
 offense Casey, but SMACK may be displaced with YAMAC (*) someday, and
 I'd hate to have wasted a capability on it.

No offense taken. Technology continues marching forward and all that.

 Using CAP_MAC_OVERRIDE makes
 sense to me - even if its not (yet/ever) honored by all MAC LSMs.

Thanks.

 I do have a question about whether one capability is sufficient in
 general for MAC. Looking at the:
 
   http://wt.xpilot.org/publications/posix.1e/download.html
 
 last draft, there are no less than 5 capabilities (p173) allocated for
 MAC. Presumably there was a good reason for 5 and not 1 back then -
 could you summarize what is different now?

There are to my mind two important differences. The first is that
my experiance with Trusted Irix (Trix from here on), which used (uses?)
capabilities and MAC together, is that the granularity is lost on
99 44/100% of programs, programmers, evaluators, admins, and problems.
You just don't get that many cases where it actually gets you anything
to have less than all the MAC capabilities. Applications that care
about MAC to the extent that they use the capabilities tend to use the
lot, if not all the time, in certain circumstances. I'm afraid that
I am not a major fan of fine grained privilege based on my experiance
with it.

The second and perhaps more important reason is that the POSIX
draft assumed a Bell  LaPadula sensitivity model, or at least
a model very much like it. What would CAP_MAC_DOWNGRADE mean on
a Smack system configured:

OneHand  OtherHandr---
OtherHandGrippingHand r---
GrippingHand OneHand  r---

What would CAP_MAC_UPGRADE mean, for that matter? It's even worse
to consider that the relationships can change.

CAP_MAC_READ and CAP_MAC_WRITE still make sense, as does
CAP_MAC_RELABEL_SUBJ. But if you have CAP_MAC_WRITE you can
do pretty much the same damage as if you have CAP_MAC_RELABEL_SUBJ,
and the other way around, and if you're not going to use one
of the other capabilities after you find out interesting things
using CAP_MAC_READ it's hard to figure why you'd bother.

Now I know that there are lots of people who don't share my
views on granularity, but I have lots of experiance with this
and the cases where it actually makes sense to break the MAC
capabilities up are rare.

That's my going in position, at any rate. I'm always open to
finding out why I'm wrong.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Casey Schaufler [EMAIL PROTECTED] wrote:

 From: Casey Schaufler [EMAIL PROTECTED]
 
 ...

I have verified this version against broken-out-2007-11-20-01-45
as well. Compiles, boots, and passes tests.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] (2.6.24-rc3 -mm only) Smack Version 11c Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Andrew Morton [EMAIL PROTECTED] wrote:

 On Tue, 20 Nov 2007 11:04:32 -0800 (PST)
 Casey Schaufler [EMAIL PROTECTED] wrote:
 
  
  --- Casey Schaufler [EMAIL PROTECTED] wrote:
  
   From: Casey Schaufler [EMAIL PROTECTED]
   
   ...
  
  I have verified this version against broken-out-2007-11-20-01-45
  as well. Compiles, boots, and passes tests.
  
 
 So is it time for me to wake up and start paying attention again?

Please? I've been very attentive, polling every few hours for
updates in -mm so that I can catch data structure changes early.
If there are any steps I can take to be helpful or to smooth the
process (grease the wheels?) let me know.

Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] For -mm only - inode_getsecurity rework

[Casey Schaufler]

From: Casey Schaufler [EMAIL PROTECTED]

This represents the rework required for changes to inode_getsecurity.
It is relative to smack24rc2v11, which is the version added to -mm,
but subsequently removed because of the change to inode_getsecurity

Signed-off-by: Casey Schaufler [EMAIL PROTECTED]

---

 security/smack/smack_lsm.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff -uprN -X linux-2.6.24-rc2-base/Documentation/dontdiff 
linux-2.6.24-rc2-smack/security/smack/smack_lsm.c 
linux-2.6.24-rc2-mm1-smack/security/smack/smack_lsm.c
--- linux-2.6.24-rc2-smack/security/smack/smack_lsm.c   2007-11-07 
21:35:41.0 -0800
+++ linux-2.6.24-rc2-mm1-smack/security/smack/smack_lsm.c   2007-11-12 
22:49:16.0 -0800
@@ -673,8 +673,8 @@ static int smack_inode_removexattr(struc
  * Returns the size of the attribute or an error code
  */
 static int smack_inode_getsecurity(const struct inode *inode,
-  const char *name, void *buffer,
-  size_t size, int err)
+  const char *name, void **buffer,
+  bool alloc)
 {
struct socket_smack *ssp;
struct socket *sock;
@@ -687,9 +687,7 @@ static int smack_inode_getsecurity(const
if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
isp = smk_of_inode(inode);
ilen = strlen(isp) + 1;
-   if (ilen  size)
-   return -EINVAL;
-   strncpy(buffer, isp, ilen);
+   *buffer = isp;
return ilen;
}
 
@@ -714,10 +712,8 @@ static int smack_inode_getsecurity(const
return -EOPNOTSUPP;
 
ilen = strlen(isp) + 1;
-   if (ilen  size)
-   rc = -EINVAL;
if (rc == 0) {
-   strncpy(buffer, isp, ilen);
+   *buffer = isp;
rc = ilen;
}
 




-
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

Re: AppArmor Security Goal

[Casey Schaufler]

--- Joshua Brindle [EMAIL PROTECTED] wrote:

 Casey Schaufler wrote:
  --- Crispin Cowan [EMAIL PROTECTED] wrote:
 

  Dr. David Alan Gilbert wrote:
  ...
 
  Can you explain why you want a non-privileged user to be able to edit
  policy? I would like to better understand the problem here.
 
  Note that John Johansen is also interested in allowing non-privileged
  users to manipulate AppArmor policy, but his view was to only allow a
  non-privileged user to further tighten the profile on a program. To me,
  that adds complexity with not much value, but if lots of users want it,
  then I'm wrong :)
  
 
  Now this is getting interesting. It looks to me as if you've implemented
  a mandatory access control scheme that some people would like to be able
  to use as a discretionary access control scheme. This is creepy after
  seeing the MCS implementation in SELinux, which is also a DAC scheme
  wacked out of a MAC scheme. Very interesting indeed.

 
 This is the same sort of thing we are trying to do in SELinux with the 
 policy management server 
 http://oss.tresys.com/projects/policy-server/wiki/PolicyServerDesign, 
 ofcourse the policy management server enforces SELinux policy on what 
 can be changed and what can't. We devised a scheme to allow the policy 
 to become more restrictive without being able to change the policy 
 'intent' using a type hierarchy.
 
 In fact I was talking to a coworker today about how this could be done 
 with smack, using the same kind of hierarchy and allowing unprivileged 
 users (eg., those without MAC_OVERRIDE) to create new smack labels 
 'under' their own which would be restricted. This is interesting because 
 of the ability to create new smack domains on the fly but since only 
 privileged users can do it it is of limited use. Imagine if a user could 
 create a new domain for their webbrowser or anything else they care to. 
 Since they can't add rules to the policy it would effectively just be a 
 user sandbox, an interesting use indeed.

It would be easy to add a label owner the same way that there's
an optional CIPSO mapping now. Writes to /smack/load would require
that the writer be the owner of the object label in the rule. I think
it would still require privilege to assign ownership, a non-parsed
write to /smack/labelowner should suffice for the mechanism. It seems
that you might need to support multiple labels for this to be really
effective, but I'm not sure why I think that. I'm also not sure that
once you draw a complete picture it won't be indistinguishable from
POSIX ACLs.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Repost - NetLabel: Introduce a new kernel configuration API for NetLabel

[Casey Schaufler]

From: Paul Moore [EMAIL PROTECTED]

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
Signed-off-by: Casey Schaufler [EMAIL PROTECTED]
---

Reposting to ensure propriety of sign-offs.


 include/net/netlabel.h |   47 --
 net/ipv4/cipso_ipv4.c  |4 -
 net/netlabel/netlabel_cipso_v4.c   |2 
 net/netlabel/netlabel_cipso_v4.h   |3 +
 net/netlabel/netlabel_domainhash.h |1 
 net/netlabel/netlabel_kapi.c   |  177 
 6 files changed, 225 insertions(+), 9 deletions(-)

diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
 #include net/netlink.h
 #include asm/atomic.h
 
+struct cipso_v4_doi;
+
 /*
  * NetLabel - A management interface for maintaining network packet label
  *mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
 };
 
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
 /* LSM security attributes */
 struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct 
netlbl_lsm_secattr *secattr)
 
 #ifdef CONFIG_NETLABEL
 /*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+  const char *domain,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
  * LSM security attribute operations
  */
 int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
 int netlbl_cache_add(const struct sk_buff *skb,
 const struct netlbl_lsm_secattr *secattr);
 #else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+  struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
 static inline int netlbl_secattr_catmap_walk(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index f18e88b..5e97315 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -546,8 +546,8 @@ int cipso_v4_doi_remove(u32 doi,
rcu_read_lock();
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
-   netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+   netlbl_cfg_map_del(dom_iter-domain,
+  audit_info);
rcu_read_unlock();
cipso_v4_cache_invalidate();
call_rcu(doi_def-rcu, callback);
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index ba0ca8d..54f9d1b 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy 
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
  * safely.
  *
  */
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
 {
struct cipso_v4_doi *ptr;
 
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum

Re: AppArmor Security Goal

[Casey Schaufler]

--- Crispin Cowan [EMAIL PROTECTED] wrote:

 Dr. David Alan Gilbert wrote:
 ...

 Can you explain why you want a non-privileged user to be able to edit
 policy? I would like to better understand the problem here.
 
 Note that John Johansen is also interested in allowing non-privileged
 users to manipulate AppArmor policy, but his view was to only allow a
 non-privileged user to further tighten the profile on a program. To me,
 that adds complexity with not much value, but if lots of users want it,
 then I'm wrong :)

Now this is getting interesting. It looks to me as if you've implemented
a mandatory access control scheme that some people would like to be able
to use as a discretionary access control scheme. This is creepy after
seeing the MCS implementation in SELinux, which is also a DAC scheme
wacked out of a MAC scheme. Very interesting indeed.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [RFC PATCH v6 05/13] SELinux: add secctx_to_secid() LSM hook

[Casey Schaufler]

--- Paul Moore [EMAIL PROTECTED] wrote:

 On Friday 09 November 2007 5:19:02 pm Casey Schaufler wrote:
  --- Paul Moore [EMAIL PROTECTED] wrote:
   Add a secctx_to_secid() LSM hook to go along with the existing
   secid_to_secctx() LSM hook.
 
  I'll bite. Where does this get used?
 
 Patch 12/13, functions netlbl_unlabel_staticadd() and 
 netlbl_unlabel_staticadddef().  It is used to convert a user supplied label 
 into a token which is later passed to the LSM; in the SELinux case it is used
 
 directly in an avc_has_perm() call.
 
 Go ahead and check, I'll wait ... just please don't bring up the whole 
 getpeercon() issue (essentially the example you chose, although you picked 
 the connectionless version) again.  Worrying about something that typically 
 happens only once (if at all) per-connection is not something I want to worry
 
 about optimizing if it causes the per-packet case to become more tedious.
 
  There. I got the righteous indignation off my chest. I say to
  go ahead with adding this to the LSM ... {snip}
 
 Sigh.  I agree, the whole tokenized label concept is conceptually very 
 annoying and I'll also agree that it can be frustrating for certain 
 implementations.  However, the world we live in (the Linux kernel) makes use 
 of these tokenized labels (secid, SID, etc) because it's all the original LSM
 
 folks could get in some places.  The fact that this works fine with SELinux 
 (actually works better than fine in some cases) is a happy coincidence and 
 probably the reason things haven't changed much.
 
 I _really_ don't want to get into the one true security model debate, but 
 the fact remains that as long as SELinux is the only LSM implementation in 
 the mainline kernel there is no reason to change this.  If/when SMACK (this 
 is really the immediate source of the righteous indignation after all, 
 right?) is merged then it will probably make sense to go revisit some of 
 those earlier decisions regarding these tokenized labels.  For me personally,
 
 right now I'm just concerned about making sure the labeled networking bits 
 work as well as we can make them work; with SELinux that means using a 
 secid/SID to speed up the per-packet access checks.  For SMACK, this will 
 probably mean passing the actual string label.  You and I have already talked
 
 about this so _you_know_ there is a SMACK friendly solution to the 
 fallback/static label functionality; I just can't justify adding code that 
 serves no purpose in the context (haha!) of the current kernel sources.
 
 You know all this Casey, so I have no idea where all of these comments are 
 coming from - bad day at work?  Somebody run over your dog?  Well, go home, 
 have a beer and forget about it for right now.  Get SMACK merged, or any 
 other LSM which highlights the same problem, and we can put that righteous 
 indignation to good use; right now, it's just plan tiresome.
 
  In Linux 2.7 I propose that we fix these problems. Not today.
 
 Un huh ... in the meantime I'm gonna work with what I have :)

Sounds like a plan with merit. I would not expect a change to existing
code without a good^H^H^H^Hbetter alternative proposed. As I don't
have such in hand at the moment, I agree that the current scheme is
pragmatic. And yes, I'm still working on getting Smack in.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 2/2] Version 11 (2.6.24-rc2) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Eric Paris [EMAIL PROTECTED] wrote:

 [snip from fs/super.c:vfs_kern_mount() just for reference]
 if (data) {
 secdata = alloc_secdata();
 if (!secdata)
 goto out_mnt;
 
 error = security_sb_copy_data(type, data, secdata);
 if (error)
 goto out_free_secdata;
 }
 
 error = type-get_sb(type, flags, name, data, mnt);
 if (error  0)
 goto out_free_secdata;
 BUG_ON(!mnt-mnt_sb);
 
 error = security_sb_kern_mount(mnt-mnt_sb, secdata);
 if (error)
 goto out_sb;
 [end snip]
 
  +/**
  + * smack_sb_copy_data - copy mount options data for processing
  + * @type: file system type
  + * @orig: where to start
  + * @smackopts
  + *
  + * Returns 0 on success or -ENOMEM on error.
  + *
  + * Copy the Smack specific mount options out of the mount
  + * options list.
  + */
  +static int smack_sb_copy_data(struct file_system_type *type, void *orig,
  + void *smackopts)
  +{
  +   char *cp, *commap, *otheropts, *dp;
  +
  +   /* Binary mount data: just copy */
  +   if (type-fs_flags  FS_BINARY_MOUNTDATA) {
  +   copy_page(smackopts, orig);
  +   return 0;
  +   }
 
 So given NFS, which may have passed you a nfs_mount_data,
 nfs_parsed_mount_data, or a nfs_clone_mount struct one page is going
 to get coppied back out to the VFS.
  +
  +   otheropts = (char *)get_zeroed_page(GFP_KERNEL);
  +   if (otheropts == NULL)
  +   return -ENOMEM;
  +
  +   for (cp = orig, commap = orig; commap != NULL; cp = commap + 1) {
  +   if (strstr(cp, SMK_FSDEFAULT) == cp)
  +   dp = smackopts;
  +   else if (strstr(cp, SMK_FSFLOOR) == cp)
  +   dp = smackopts;
  +   else if (strstr(cp, SMK_FSHAT) == cp)
  +   dp = smackopts;
  +   else if (strstr(cp, SMK_FSROOT) == cp)
  +   dp = smackopts;
  +   else
  +   dp = otheropts;
  +
  +   commap = strchr(cp, ',');
  +   if (commap != NULL)
  +   *commap = '\0';
  +
  +   if (*dp != '\0')
  +   strcat(dp, ,);
  +   strcat(dp, cp);
  +   }
  +
  +   strcpy(orig, otheropts);
  +   free_page((unsigned long)otheropts);
  +
  +   return 0;
  +}
  +
  +/**
  + * smack_sb_kern_mount - Smack specific mount processing
  + * @sb: the file system superblock
  + * @data: the smack mount options
  + *
  + * Returns 0 on success, an error code on failure
  + */
  +static int smack_sb_kern_mount(struct super_block *sb, void *data)
  +{
  +   struct dentry *root = sb-s_root;
  +   struct inode *inode = root-d_inode;
  +   struct superblock_smack *sp = sb-s_security;
  +   struct inode_smack *isp;
  +   char *op;
  +   char *commap;
  +   char *nsp;
  +
  +   spin_lock(sp-smk_sblock);
  +   if (sp-smk_initialized != 0) {
  +   spin_unlock(sp-smk_sblock);
  +   return 0;
  +   }
  +   sp-smk_initialized = 1;
  +   spin_unlock(sp-smk_sblock);
  +
  +   for (op = data; op != NULL; op = commap) {
 
 Here you walk this page of binary NFS data looking for your stuff.
 And while I assume its unlikely you find anything you like on this
 page and go wrong, its not impossible.
 
 SELinux tried to solve this problem right here in its equivalent
 function years ago, but it has since been despised by the FS people
 and now i'm trying to make everyone happy.  I'd love you comment on
 how you plan to support NFS and other filesystems which use
 FS_BINARY_MOUNTDATA)

I think I'd best say that I need to look at what you've got so far
and see how best to make use of it, because my current plan is nowhere
near as good as yours.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH -v3] SELinux: Add get, set, and cloning of superblock security information

[Casey Schaufler]

 =selinux_umount,
  +   .sb_get_mnt_opts =  selinux_get_mnt_opts,
  +   .sb_set_mnt_opts =  selinux_set_mnt_opts,
  +   .sb_clone_mnt_opts =selinux_sb_clone_mnt_opts,
   
  .inode_alloc_security = selinux_inode_alloc_security,
  .inode_free_security =  selinux_inode_free_security,
  diff --git a/security/selinux/include/objsec.h
 b/security/selinux/include/objsec.h
  index 642a9fd..4138a80 100644
  --- a/security/selinux/include/objsec.h
  +++ b/security/selinux/include/objsec.h
  @@ -65,6 +65,7 @@ struct superblock_security_struct {
  u32 mntpoint_sid;   /* SECURITY_FS_USE_MNTPOINT context for 
  files */
  unsigned int behavior;  /* labeling behavior */
  unsigned char initialized;  /* initialization flag */
  +   unsigned char flags;/* which mount options were specified */
  unsigned char proc; /* proc fs */
  struct mutex lock;
  struct list_head isec_head;
  
  
  
  --
  This message was distributed to subscribers of the selinux mailing list.
  If you no longer wish to subscribe, send mail to [EMAIL PROTECTED]
 with
  the words unsubscribe selinux without quotes as the message.
 -- 
 Stephen Smalley
 National Security Agency
 
 
 --
 This message was distributed to subscribers of the selinux mailing list.
 If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
 the words unsubscribe selinux without quotes as the message.
 
 
 


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [RFC PATCH v6 05/13] SELinux: add secctx_to_secid() LSM hook

[Casey Schaufler]

--- Paul Moore [EMAIL PROTECTED] wrote:

 Add a secctx_to_secid() LSM hook to go along with the existing
 secid_to_secctx() LSM hook.

I'll bite. Where does this get used?

There are already places in the networking and audit code where
a secid is gotten and saved for the sole purpose of getting a secctx
at some later time. My favorite example:

 static void ip_cmsg_recv_security(struct msghdr *msg, struct sk_buff *skb)
 {
 char *secdata;
 u32 seclen, secid;
 int err;

In the Smack case what's in skb is the secctx.

 err = security_socket_getpeersec_dgram(NULL, skb, secid);
 if (err)
 return;

Smack pulls the secctx off the packet and finds a secid for it.

 err = security_secid_to_secctx(secid, secdata, seclen);
 if (err)
 return;

Just so that it can turn around and look up the secctx it had in the
first place.

 put_cmsg(msg, SOL_IP, SCM_SECURITY, seclen, secdata);
 security_release_secctx(secdata, seclen);

Fortunatly, this is no-op.

 }

I expect that the purpose of the proposed secctx_to_secid() is to
make it easier to implement more of these cases, where the only
reason to do the conversion is to have something to convert back
later. With SELinux as the only consumer of the LSM, and with the
SELinux secid mindset I suppose this could make sense. It would
also be perfectly reasonable if there was anything to do with a
secid except convert it to a secctx, but there isn't.

There. I got the righteous indignation off my chest. I say to
go ahead with adding this to the LSM because I need it to for
dealing with the aformentioned audit code, which I have looked
into fixing to use secctx instead of secid, and determined that
there are a couple cases where you end up with the secid in any
case.

In Linux 2.7 I propose that we fix these problems. Not today.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH -v3] SELinux: Add get, set, and cloning of superblock security information

[Casey Schaufler]

;
 + goto out_err;
 + }
 + break;
 +
 + default:
 + rc = -EINVAL;
 + printk(KERN_WARNING SELinux:  unknown mount option\n);
 + goto out_err;
  
 - /* Initialize any other inodes associated with the superblock, e.g.
 -inodes created prior to initial policy load or inodes created
 -during get_sb by a pseudo filesystem that directly
 -populates itself. */
 - spin_lock(sbsec-isec_lock);
 -next_inode:
 - if (!list_empty(sbsec-isec_head)) {
 - struct inode_security_struct *isec =
 - list_entry(sbsec-isec_head.next,
 -struct inode_security_struct, list);
 - struct inode *inode = isec-inode;
 - spin_unlock(sbsec-isec_lock);
 - inode = igrab(inode);
 - if (inode) {
 - if (!IS_PRIVATE (inode))
 - inode_doinit(inode);
 - iput(inode);
   }
 - spin_lock(sbsec-isec_lock);
 - list_del_init(isec-list);
 - goto next_inode;
   }
 - spin_unlock(sbsec-isec_lock);
 +
 +build_flags:
 + if (fscontext) {
 + mnt_opts[num_mnt_opts] = fscontext;
 + mnt_opts_flags[num_mnt_opts++] = FSCONTEXT_MNT;
 + }
 + if (context) {
 + mnt_opts[num_mnt_opts] = context;
 + mnt_opts_flags[num_mnt_opts++] = CONTEXT_MNT;
 + }
 + if (rootcontext) {
 + mnt_opts[num_mnt_opts] = rootcontext;
 + mnt_opts_flags[num_mnt_opts++] = ROOTCONTEXT_MNT;
 + }
 + if (defcontext) {
 + mnt_opts[num_mnt_opts] = defcontext;
 + mnt_opts_flags[num_mnt_opts++] = DEFCONTEXT_MNT;
 + }
 +
  out:
 - mutex_unlock(sbsec-lock);
 + rc = selinux_set_mnt_opts(sb, mnt_opts, mnt_opts_flags, num_mnt_opts);
 +out_err:
 + kfree(context);
 + kfree(defcontext);
 + kfree(fscontext);
 + kfree(rootcontext);
   return rc;
  }
  
 @@ -4800,6 +5038,9 @@ static struct security_operations selinux_ops = {
   .sb_statfs =selinux_sb_statfs,
   .sb_mount = selinux_mount,
   .sb_umount =selinux_umount,
 + .sb_get_mnt_opts =  selinux_get_mnt_opts,
 + .sb_set_mnt_opts =  selinux_set_mnt_opts,
 + .sb_clone_mnt_opts =selinux_sb_clone_mnt_opts,
  
   .inode_alloc_security = selinux_inode_alloc_security,
   .inode_free_security =  selinux_inode_free_security,
 diff --git a/security/selinux/include/objsec.h
 b/security/selinux/include/objsec.h
 index 642a9fd..4138a80 100644
 --- a/security/selinux/include/objsec.h
 +++ b/security/selinux/include/objsec.h
 @@ -65,6 +65,7 @@ struct superblock_security_struct {
   u32 mntpoint_sid;   /* SECURITY_FS_USE_MNTPOINT context for 
 files */
   unsigned int behavior;  /* labeling behavior */
   unsigned char initialized;  /* initialization flag */
 + unsigned char flags;/* which mount options were specified */
   unsigned char proc; /* proc fs */
   struct mutex lock;
   struct list_head isec_head;
 
 
 
 


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH 0/2] Version 11 (2.6.24-rc2) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

This is version 11 of the Simplified Mandatory Access Control Kernel.

The whole thing as available on the Smack home page at

http://schaufler-ca.com

The attachments to this message are not kernel code.
They are early versions of the smackload and smackcipso
programs, and are included in the hope that doing so
may reduce (I certainly wouldn't count on it eliminating)
whinging about the revised versions of smack_write_load()
and smack_write_cipso().

The /smack/load and /smack/cipso special files are a minor
component of Smack, and much too much energy has gone into
them, and I would much prefer that people who don't like
Smack crux about things that are important rather than the
details and moral implications of parsers in kernel code.

Writes to /smack/load are now required to have this format:

SubjectLabel ObjectLabel Mode[decorations]
| 24 bytes  || 24 bytes ||4 ||undefined  |

A write to /smack/load must be 52 or more bytes in length.
The 4 mode bytes must be of the form [rR-][wW-][xX-][aA-],
in that order. The regular rules enforced by smack_import()
apply to the strings at offset 0 and offset 24.

Writes to /smack/cipso are now required to have this format:

LabelMapped Level CatCount [cat]...
| 24 bytes || 4  ||  4| |4|


A write to /smack/cipso must be at least 32 bytes long,
and also must be 32 + (4 * CatCount) bytes long. If there
are no categories CatCount must be 0   . The label is
read using smack_import(). All other values are left
justified (2   , not2) integers in 4 bytes.

Since these formats are so fussy I have provided programs
that take care of that. They are still human readable text,
but no longer require parsing in the kernel. It is my sincere
hope that we can put the bruhaha about parsing to bed.

Two patches here. Paul Moore's netlabel api patch has been updated
due to unrelated changes in that code.


/*
 * smackload - properly format smack access rules for
 * loading into the kernel by writing to /smack/load.
 *
 */
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include string.h

#define LSIZE 23
#define ASIZE 4

int
main(int argc, char *argv[])
{
int loadfd;
char line[80];
char rule[LSIZE + LSIZE + ASIZE + 3];
char subject[LSIZE+1];
char object[LSIZE+1];
char accesses[ASIZE+1];
char real[ASIZE+1];
char *cp;
int i;
int err;

loadfd = open(/smack/load, O_RDWR);
if (loadfd  0) {
perror(opening /smack/load);
exit(1);
}

while (fgets(line, 80, stdin) != NULL) {
err = 0;
if ((cp = strchr(line, '\n')) != NULL)
*cp = '\0';
if (sscanf(line,%23s %23s %4s,subject,object,accesses) != 3) 
err = 1;
else {
strcpy(real, );
for (i = 0;
 i  ASIZE  accesses[i] != '\0'  err == 0;
 i++) {
switch (accesses[i]) {
case 'r':
case 'R':
real[0] = 'r';
break;
case 'w':
case 'W':
real[1] = 'w';
break;
case 'x':
case 'X':
real[2] = 'x';
break;
case 'a':
case 'A':
real[3] = 'a';
break;
case '\0':
case '-':
break;
default:
err = 1;
break;
}
}
}
if (err == 0) {
fprintf(stderr, Good input line \%s\\n, line);
sprintf(rule, %-23s %-23s %4s, subject,object,real);
fprintf(stderr, Sending in line \%s\\n, rule);
err = write(loadfd, rule, LSIZE + LSIZE + ASIZE + 2);
if (err  0)
perror(writing /smack/load);
}
else
fprintf(stderr, Bad input line \%s\\n, line);
}
exit(0);
}
/*
 * smackcipso - properly format smack access cipsos for
 * loading into the kernel by writing to /smack/cipso.
 *
 */
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h

[PATCH 1/2] NetLabel: Introduce a new kernel configuration API for NetLabel - Version 11 (2.6.24-rc2) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

From: Paul Moore [EMAIL PROTECTED]

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---

 include/net/netlabel.h |   47 --
 net/ipv4/cipso_ipv4.c  |4 -
 net/netlabel/netlabel_cipso_v4.c   |2 
 net/netlabel/netlabel_cipso_v4.h   |3 +
 net/netlabel/netlabel_domainhash.h |1 
 net/netlabel/netlabel_kapi.c   |  177 
 6 files changed, 225 insertions(+), 9 deletions(-)

diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
 #include net/netlink.h
 #include asm/atomic.h
 
+struct cipso_v4_doi;
+
 /*
  * NetLabel - A management interface for maintaining network packet label
  *mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
 };
 
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
 /* LSM security attributes */
 struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct 
netlbl_lsm_secattr *secattr)
 
 #ifdef CONFIG_NETLABEL
 /*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+  const char *domain,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
  * LSM security attribute operations
  */
 int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
 int netlbl_cache_add(const struct sk_buff *skb,
 const struct netlbl_lsm_secattr *secattr);
 #else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+  struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
 static inline int netlbl_secattr_catmap_walk(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index f18e88b..5e97315 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -546,8 +546,8 @@ int cipso_v4_doi_remove(u32 doi,
rcu_read_lock();
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
-   netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+   netlbl_cfg_map_del(dom_iter-domain,
+  audit_info);
rcu_read_unlock();
cipso_v4_cache_invalidate();
call_rcu(doi_def-rcu, callback);
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index ba0ca8d..54f9d1b 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy 
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
  * safely.
  *
  */
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
 {
struct cipso_v4_doi *ptr;
 
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
 /* NetLabel protocol functions */
 int netlbl_cipsov4_genl_init(void);
 
+/* Free the memory 

Re: [PATCH] NetLabel: Introduce a new kernel configuration API for NetLabel - For 2.6.24-rc-git11 - Smack Version 10

[Casey Schaufler]

--- Joshua Brindle [EMAIL PROTECTED] wrote:

 Joshua Brindle wrote:
  Casey Schaufler wrote:
  From: Paul Moore [EMAIL PROTECTED]
 
  Add a new set of configuration functions to the NetLabel/LSM API so that
  LSMs can perform their own configuration of the NetLabel subsystem 
  without
  relying on assistance from userspace.

  I'm still not receiving the actual patch email on lsm (perhaps its too 
  long and should be split up..) so I'll just respond on this email. 
  Using the v10 patches on your website I'm still seeing strange 
  behavior where echo foo  /proc/self/attr/current changes the label of 
  every process on the system to foo (verified with both ps -AZ and cat 
  /proc/1/attr/current).
 
 Actually I'm getting more strange behavior:
 
 On terminal 1 I do:
 echo foo  /proc/self/attr/current
 then ps -AZ shows foo for every process
 touch somefile; attr -S -g SMACK64 somefile says foo
 
 On terminal 2 I do:
 ps -AZ and everything shows up as _
 cat /proc/$pid of bash on term 1/attr/current is _

Now this I can explain. Every task has it's own correct
label. The problem is a missing smack_getprocattr() hook.
ps is getting the value for current on the current process,
not that of the named process. Interestingly, the Smack label
of /proc/xxx/attr/current is correct.

So the fix is to put in the smack_getprocattr() hook.
Easily accomplished. Thank you for the informative and
helpful report.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] NetLabel: Introduce a new kernel configuration API for NetLabel - For 2.6.24-rc-git11 - Smack Version 10

[Casey Schaufler]

--- Casey Schaufler [EMAIL PROTECTED] wrote:

 
 --- Joshua Brindle [EMAIL PROTECTED] wrote:
 
  Joshua Brindle wrote:
   Casey Schaufler wrote:
   From: Paul Moore [EMAIL PROTECTED]
  
   Add a new set of configuration functions to the NetLabel/LSM API so that
   LSMs can perform their own configuration of the NetLabel subsystem 
   without
   relying on assistance from userspace.
 
   I'm still not receiving the actual patch email on lsm (perhaps its too 
   long and should be split up..) so I'll just respond on this email. 
   Using the v10 patches on your website I'm still seeing strange 
   behavior where echo foo  /proc/self/attr/current changes the label of 
   every process on the system to foo (verified with both ps -AZ and cat 
   /proc/1/attr/current).
  
  Actually I'm getting more strange behavior:
  
  On terminal 1 I do:
  echo foo  /proc/self/attr/current
  then ps -AZ shows foo for every process
  touch somefile; attr -S -g SMACK64 somefile says foo
  
  On terminal 2 I do:
  ps -AZ and everything shows up as _
  cat /proc/$pid of bash on term 1/attr/current is _
 
 Now this I can explain. Every task has it's own correct
 label. The problem is a missing smack_getprocattr() hook.
 ps is getting the value for current on the current process,
 not that of the named process. Interestingly, the Smack label
 of /proc/xxx/attr/current is correct.

That's what I get for responding too quickly. There is a
smack_getprocattr() hook, it's just wrong. Fixed for the
next version. 

Thank you again. 


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Cliffe [EMAIL PROTECTED] wrote:

 As good an idea POSIX capabilities might be,

Now that's a refreshing comment. Thank you.

 not all security problems 
 can be solved with a bitmap of on/off permissions.

There are people (I'm not one of them) who figure that you
can solve all the security problems by applying sufficiently
fine granularity of on/off permissions.

 Peter Dolding wrote:
 lots o stuff
 
 Ok but what happens to the principle of least privilege?
 
 What if we want AppArmor to confine that application to use a particular 
 set of ports?
 
 Do you propose having a capability for each port? how about protocols?

While you're at it, how about a capability for each possible
directory entry name?

 So unless my understanding of capabilities is fundamentally flawed 
 (which it may be - I have not spent time reviewing recent changes) 
 obviously Linux capabilities does not provide a solution to every problem.

Of course they don't. The only problem they are intended
to solve, and I really mean this, is the association of uid 0
with privilege. That's it. You would be better off with a single
CAP_GODLIKE than with uid 0 having all privilege all the time.
Fine grained capabilities are a bonus, and there are lots of
people who think that it would be really nifty if there were a
separate capability for each if in the kernel. I personally
don't see need for more than about 20. That is a matter of taste.
DG/UX ended up with 330 and I say that's too many.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Tetsuo Handa [EMAIL PROTECTED] wrote:

 Hello.
 
 Casey Schaufler wrote:
  Fine grained capabilities are a bonus, and there are lots of
  people who think that it would be really nifty if there were a
  separate capability for each if in the kernel. I personally
  don't see need for more than about 20. That is a matter of taste.
  DG/UX ended up with 330 and I say that's too many.
 
 TOMOYO Linux has own (non-POSIX) capability that can support 65536
 capabilities
 if there *were* a separate capability for each if in the kernel.

http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/tomoyo-capability.diff?root=tomoyoview=markup
 
 The reason I don't use POSIX capability is that the maximum types are limited
 to
 bitwidth of a variable (i.e. currently 32, or are we going to extend it to
 64).
 This leads to abuse of CAP_SYS_ADMIN capability.

That is a matter of taste. 

 In other words, it makes fine-grained privilege division impossible.

I personally believe that a finer granularity than about 20
is too fine. I understand that this is a minority opinion.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser

[Casey Schaufler]

--- Ahmed S. Darwish [EMAIL PROTECTED] wrote:

 On 11/4/07, Pavel Machek [EMAIL PROTECTED] wrote:
  Hi!
 
Still to come:
   
  - Final cleanup of smack_load_write and smack_cipso_write.
  
   Hi All,
  
   After agreeing with Casey on the load input grammar yesterday, here's
   the final grammar and its parser (which needs more testing):
  
   A Smack Rule in an egrep format is:
  
   ^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n
  
   where Subject/Object strings are in the form:
  
   ^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$
 
  Can we avoid string parsers in the kernel?

Woof. We've devolved into Al saying it must be done this way,
and Pavel saying it can't be done this way.

That's OK. Maybe it's time that I stepped back and came up
with a twisted mechanism for achieving my ends, as the obvious
mechanism appears as if it will always call down disapproval.
 
 I've suggested that at first, but (hoping not to misquote Al) Al viro
 said that the parsing is simple enough and no need exists for a
 user-space utility.
 
 
   +static inline int isblank(char c)
   +{
   + return (c == ' ' || c == '\t');
   +}
 
  This sounds like enough for 'NAK'.
 
 
 Would you please show the reason for the NAK so I can modify the code ?

yeah, my head needs scratching after that one.

 
 Thank you,
 
  Pavel,
  who still thinks smack rules should be parsed
  in userspace and compiled into selinux rules...

Casey, who still thinks Pavel doesn't get it.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Defense in depth: LSM *modules*, not a static interface

[Casey Schaufler]

--- Crispin Cowan [EMAIL PROTECTED] wrote:

 Al Viro wrote:
  On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:

  Defense in depth has long been recognised as an important secure design 
  principle. Security is best achieved using a layered approach.
  
   Layered approach is not a magic incantation to excuse any bit of snake
  oil.  Homeopathic remedies might not harm (pure water is pure water),
  but that's not an excuse for quackery.  And frankly, most of the
  security improvement crowd sound exactly like woo-peddlers.

 Frank's point was that the static interface makes layering somewhere
 between impractical and impossible. The static interface change should
 be dumped so that layering is at least possible. Whether any given
 security module is worth while is a separate issue.
 
 I.e. that there are bad medicines around is a poor excuse to ban
 syringes and demand that everyone be born with a strong immune system.
 
 Why is it that security flame wars always end up reasoning with absurd
 analogies? :-)

That's my fault, sorry. I don't know why it's my fault,
but that's where it usually ends up and I thought I'd get
the blame bit out of the way. Gotta go squeeze some legless
reptiles now.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Kazuki Omo(Company) [EMAIL PROTECTED] wrote:

 Dear, Folks,
 
 Now we are planning to submit LIDS to mainline.
 (As you know, it already written for supporing LSM for several years.)
 
 When we will finish to re-write documentation and some FAQ, then
 we will be able to submit the patch.
 
 Sincerely,
 
 OMO

Most excellent. Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Jan Engelhardt [EMAIL PROTECTED] wrote:

 
 (please do not drop Cc, or I would have lost this thread part if I had 
 not been on lkml. And sometimes I am not because of the volume. Thanks.)
 
 On Oct 30 2007 15:13, Peter Dolding wrote:
 On 10/30/07, Crispin Cowan [EMAIL PROTECTED] wrote:
 
  * I have no clue what family to put MultiADM or Dazuko into
 
 MultiADMIN falls under o my god head ache.  This is more a posix
 standard feature altered ie 1 root user turned into many.  This really
 risks breaking the other models as a LSM.
 
 I disagree.
 
 Traditionally, Linux has given a process all capabilities when the
 UID changed to 0 (either by setuid(2) or executing a SUID binary).
 This has been relieved over the years, and right now with LSMs in the
 field, it is possible to 'deactivate' this special case for UID 0.
 
 SELinux does not have this special case for UID 0. Neither does it
 seem to use capabilities (quick grep through the source). So
 basically, all users are the same, and no one has capabilities by
 default. Does SELinux thus break with other LSMs?
 
 Now assume a SELinux system where all users have all capabilities
 (and the policy that is in place restricts the use of these
 capabilities then) -- should not be that unlikely. Does that break
 with other LSMs?

As some of the early Smack discussions brought out, some LSMs
including Smack will be perfectly happy with the traditional
Linux privilege mechanisms (choice of root and/or capablities)
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Peter Dolding [EMAIL PROTECTED] wrote:


 Lets end the bitrot.  Start having bits go into the main OS security
 features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like Security Expert or Trust
Technologist with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Rob Meijer [EMAIL PROTECTED] wrote:


  * The proposal only allows a single implementation of each formal
model. In theory, theory is just like practice, but in practice it
is not. SMACK and SELinux follow substantially similar formal
models (not exactly the same) so should we exclude one and keep
the other? No, of course not, because in practice they are very
different.
 
 I would think the two may benefit from a role as described above.
 But I was thinking more in the line of new modules that may again
 implement this same model, and would thus benefit from interaction with
 this 'model maintainer' role.

The Smack development has benefited greatly from comments, suggestions,
and bug reports from members of the SELinux community. Further, I have
had no trouble whatever sharing the netlabel component with SELinux.
Audit is another matter as it requires some work to get the SELinux
dependencies out, but everyone's been receptive to proposals there.
Why on earth would I want some 'model maintainer' passing judgements
on my work in progress? The only thing I can imagine a 'model
maintainer' doing is obstructing innovation. Unless it was me, of
course. Linus is right, you know.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 0/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Joshua Brindle [EMAIL PROTECTED] wrote:

 Casey Schaufler wrote:
  The Smack patch and Paul Moore's netlabel API patch,
  together for 2.6.24-rc1. Paul's changes are identical
  to the previous posting, but it's been a while so they're
  here again.
 
  The sole intent of change has been to address locking
  and/or list processing issues. Please don't hesitate to
  point out any problems that you might see or suggest
  alternatives where things might not be to your liking.
 
  This version is aimed at 2.6.24, and has been tested
  against 2.6.24-rc1.

 with both of these patches applied to 2.6.24-rc1 I get the following 
 oops when nfsd starts:
 
 BUG: unable to handle kernel NULL pointer dereference at virtual address 
 013c
 printing eip: c01d7e39 *pde = 
 Oops:  [#1] SMP

 

Thanks for the bug report. I have just discovered that it is possible
to have a virtual disk go virtually bad under VMware. I will be
looking at this as soon as I recover.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Ahmed S. Darwish [EMAIL PROTECTED] wrote:

 Hi Casey,
 
 Casey [EMAIL PROTECTED] wrote:
 
  This version is again aimed at addressing Al Viro's issues in
  smackfs. Ahmed Darwish has again contributed in the repair of the
  locking issues there. The move to 2.6.24 was also an important
  release incentive.
 
 
 My patches mentiond above is not applied in this version. The same 
 lock issues remain. Did you forget applying them ?

The patch I sent out was one version older than the one I
intended to send. If I can recover the #$%^*( disk I should
have an update that includes those fixes presently. If not it
may take a day or two longer. You have not been forgotten.
Thank you for your contribution.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Al Viro [EMAIL PROTECTED] wrote:

 On Sat, Oct 27, 2007 at 11:01:12AM +0200, Ahmed S. Darwish wrote:
  The problem here (As discussed in private mails) is that the for loop 
  assumes that the beginning of given user-space buffer is the beginning
  of a rule. This leads to situations where the rule becomes ecret 20,
  or cret 20 instead of Secret 20. Big input buffers/files leads 
  smack to recieve a rule like Secret 20 in fragmented chunks like:
  
  write(lots of rules before ours\nSec, ..)
  write(r, 1, ..)
  write(et 20\nremaing rules after ours, ..)
  
  Parsing a rule in such tough conditions in _kernel space_ is very
  hard. I began to feel that it will be much easier if we do the parsing 
  in a userspace utility and let smack accept only small buffers (80 char). 
 
 For crying out louf, all it takes is a finite state machine...  BTW, folks,
 your parser *and* input language suck.  Really.  Silently allowing noise
 is Dumb(tm).

I was planning to patient Dumb, but if you've already got a copywrite
on it I'll have to go a different route. Carp.

 Please, write the grammar down and _follow_ _it_.

Good idea. I'll do it.

  ...
 
 Come on, people, this is ridiculous - why bother reinventing the wheels for
 the stuff that belongs to exercises halfway through any self-respecting
 introductory textbook?  Scary parser, my arse...

That code is in need of cleansing. With bleach. Yes, it's on my list.
I managed to get my virtual disk back, found how I messed up on v9,
and now have a (long) list of improvements and fixes.

No rest for the wicked.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Stephen Smalley [EMAIL PROTECTED] wrote:

 On Wed, 2007-10-24 at 20:46 -0700, Casey Schaufler wrote:
 ...
  +Smack does not implement Domain Type Enforcement (DTE). If
  +you want DTE Linux has an implementation called SELinux.
  +Those who really want DTE are encouraged to use SELinux.
  +Those who don't know what DTE is are encouraged to compare
  +SELinux with Smack to determine which mechanisms are best
  +suited to the problem at hand.
 
 Nit: SELinux does not implement DTE.  DTE was a scheme introduced by Lee
 Badger et al to apply implicit typing based on pathname as a variant of
 the original type enforcement model.  SELinux is an implementation of
 the Flask security architecture for flexible MAC, along with an example
 security server that implements RBAC, TE, and MLS models, but not
 limited to them.

Okey Dokey. I'll fix that up.

Thank you for the review. I will have a look at all of the
individual comments.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH RFC 1/2] capabilities: fix compilation with strict type checking (v2)

[Casey Schaufler]

--- Chris Wright [EMAIL PROTECTED] wrote:

 * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
  Here is a new version of the 64-bit capability patches I was supposed
  to send last week I think.
  
  This patch could stand alone without the 64-bit caps, but should
  definately not be applied anywhere until it has been better
  reviewed.  It is the alternative to the patch removing the
  capability type checking code.
 
 How likely is  64?

If the Granularity Gremlins get loose the answer is 100%.
DG/UX ended up with over 330.

Fortunately the GGs have a playpen already in SELinux.
I suggest that the capabilities maintainer be very stingy
and refer anyone who's need isn't pretty obvious there.
This means that the folks who want to divide CAP_SYSADMIN
are going to be disappointed with what they get, but some
level of restraint is important.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

[Casey Schaufler]

--- Chris Wright [EMAIL PROTECTED] wrote:

 * Casey Schaufler ([EMAIL PROTECTED]) wrote:
  And don't give me the old LKML is a tough crowd feldercarb.
  Security modules have been much worse. Innovation, even in
  security, is a good thing and treating people harshly, even
  for their own good, is an impediment to innovation.
 
 I agree that innovation is critical to the success of Linux, and security
 is not immune to that.  The trouble is that most of the security modules
 that have come forward have had some real serious shortcomings.  I do
 believe it is prudent to keep in-tree security sensitive code under
 high scrutiny because we do not want to create security holes by adding
 problematic security code.

I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like name based access
control is rediculous, and a module can't be any good if it doesn't
deal with all objects, or the granularity isn't fine enough. Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.

Sure, some LSM proposals will be lousy, and some really will be
better done as an SELinux policy module. Some will even have merit
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.



Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH 0/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

The Smack patch and Paul Moore's netlabel API patch,
together for 2.6.24-rc1. Paul's changes are identical
to the previous posting, but it's been a while so they're
here again.

The sole intent of change has been to address locking
and/or list processing issues. Please don't hesitate to
point out any problems that you might see or suggest
alternatives where things might not be to your liking.

This version is aimed at 2.6.24, and has been tested
against 2.6.24-rc1.

Thank you again.
-
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

[PATCH 1/2] [NetLabel] Introduce a new kernel configuration API for NetLabel - Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

From: Paul Moore [EMAIL PROTECTED]

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---

 include/net/netlabel.h |   47 --
 net/ipv4/cipso_ipv4.c  |4 -
 net/netlabel/netlabel_cipso_v4.c   |2 
 net/netlabel/netlabel_cipso_v4.h   |3 +
 net/netlabel/netlabel_domainhash.h |1 
 net/netlabel/netlabel_kapi.c   |  177 
 6 files changed, 225 insertions(+), 9 deletions(-)

diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
 #include net/netlink.h
 #include asm/atomic.h
 
+struct cipso_v4_doi;
+
 /*
  * NetLabel - A management interface for maintaining network packet label
  *mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
 };
 
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
 /* LSM security attributes */
 struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct 
netlbl_lsm_secattr *secattr)
 
 #ifdef CONFIG_NETLABEL
 /*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+  const char *domain,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
  * LSM security attribute operations
  */
 int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
 int netlbl_cache_add(const struct sk_buff *skb,
 const struct netlbl_lsm_secattr *secattr);
 #else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+  struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
 static inline int netlbl_secattr_catmap_walk(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
-   netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+   netlbl_cfg_map_del(dom_iter-domain,
+  audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
 
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy 
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
  * safely.
  *
  */
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
 {
struct cipso_v4_doi *ptr;
 
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
 /* NetLabel protocol functions */
 int netlbl_cipsov4_genl_init(void);
 
+/* Free the memory associated with a CIPSOv4 DOI 

Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Al Viro [EMAIL PROTECTED] wrote:

 On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
 
 At random:
 
  +static int smack_netlabel(struct sock *sk)
  +{
  +   static int initialized;
  +   struct socket_smack *ssp = sk-sk_security;
  +   struct netlbl_lsm_secattr secattr;
  +   int rc = 0;
  +
  +   if (!initialized) {
  +   smk_cipso_doi();
  +   initialized = 1;
  +   }
 
 And just what happens if another task calls the same while we are
 blocked on allocation in smk_cipso_doi()?

I assume that swapping the two lines,

initialized = 1;
smk_cipso_doi();

although it looks like it would suffice, isn't really good enough.

 Another problem is your handling of smk_known - you add to head under
 mutex; fine.  However, you read without one _and_ have no barriers
 in initializing new list entries.
 
 Think what happens if CPU1 adds to list and CPU2 sees write to smk_known
 *before* it sees write to -smk_next.  We see a single-element list and
 we'll be lucky if that single entry won't be FUBAR.

Help me understand this:

if (skp == NULL) {
skp = kzalloc(sizeof(struct smack_known), GFP_KERNEL);
if (skp != NULL) {
skp-smk_next = smack_known;
strncpy(skp-smk_known, smack, SMK_MAXLEN);
skp-smk_secid = smack_next_secid++;
skp-smk_cipso = NULL;
spin_lock_init(skp-smk_cipsolock);
smack_known = skp;
}
}

CPU1 sets smk_next to smack_known. 
CPU1 fills in the rest of the entry.
CPU1 sets smack_known to skp (the entry).

CPU2 will either see the old value for smack_known,
in which case this entry isn't actually on the list yet,
or it will see the new value in smack_known. Since smk_next
is set before the entry is added to the list, it seems that
the scenario you've outlined shouldn't happen. I assume then
that you're refering to a case where the memory seen by the
two CPUs doesn't match. That still wouldn't account for the
single entry list notion. If CPU2 sees anything in smk_next
it should be the old smack_known.



Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

[Casey Schaufler]

--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Andrew Morton ([EMAIL PROTECTED]):
  On Tue, 16 Oct 2007 16:41:59 -0500
  Serge E. Hallyn [EMAIL PROTECTED] wrote:
  
   To properly test this the libcap code will need to be updated first,
   which I'm looking at now...
  
  This seems fairly significant.  I asusme that this patch won't break
  presently-deployed libcap?
 
 It will break libcap.  And I'm not sure of the right way to address it.
 So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and
 Kaigai.
 
 We can introduce new capget64() and capset64() calls, and have
 capget() return -EINVAL or -EAGAIN if a high bit would be needed to
 accurately get the task's capabilities.
 
 Or we can require a new libcap, since capget and capset aren't
 required for most day-to-day function anyway.
 
 I guess now that I've written this out, it seems pretty clear
 that capget64() and capget64() are the way to go.  Any objections?

Not from me. Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 7 (2.6.23) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Ahmed S. Darwish [EMAIL PROTECTED] wrote:

 Hi Casey,
 
 On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
  
  +
  +CIPSO Configuration
  +
  +It is normally unnecessary to specify the CIPSO configuration. The default
  +values used by the system handle all internal cases. Smack will compose
 CIPSO
  +label values to match the Smack labels being used without administrative
  +intervention. 
 
 
 I have two issues with CIPSO and Smack:
 
 1-
 
 Using default configuration (system startup script + smacfs fstab line),
 system
 can't access any service outside the Lan. ICMP parameter problem message
 always
 appear from the first Wan router (traceroute + tcpdump at [1]).
 
 Services inside the LAN can be accessed normally. System can connect to a Lan
 Windows share. It also connects to the gateway HTTP server easily.
 
 After some tweaking, I discovered that using CIPSOv6 solves all above
 problems:
 $ echo -n NLBL_CIPSOv6  /smack/nltype
 
 Is this a normal behaviour ?

Well ... sort of. CIPSOv6 isn't actually implemented in the
labeled networking code. What you're seeing is unlabeled packets.

As far as CIPSOv4 and your WAN router, It is possible that it is
configured either to reject CIPSO packets or to allow only CIPSO
packets in a particular DOI or to enforce a CIPSO policy of its
own.

 2-
 
  4. Any access requested on an object labeled * is permitted.
 [...]
  +Unlabeled packets that come into the system will be given the
  +ambient label.
 
 Default conf let the ambient attribute = _ which works fine. Setting ambient
 = *
 stops all external (non lo) network traffic. Did I miss another use of
 ambient
 or this is a normal behaviour ?.

An IP operation is considered a write from the sender to the receiver.
The packet label is the label of the sender. Thus, in the unlabeled
packet case, the ambient label (* in your case) is attached to packet,
and the access check always denies access because of the first access
rule, which is that a subject with a star label will always be denied
access.

  +Administration
  +
  +Smack supports some mount options:
  +
  +   smackfsdef=label: specifies the label to give files that lack
  +   the Smack label extended attribute.
  +
 
 Although using smackfsdef=* as a mount option, all my system files have the
 floor
 attribute. Most of the /dev files have the * attribute though.

The smackfsdef mount option applies to files that don't actually
have the security.SMACK64 attribute. If those files have the attribute
whatever value is associated with it will be used.


Thank you.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Casey Schaufler ([EMAIL PROTECTED]):
  ...
  Good suggestion. In fact, that is exactly how I approached my
  first two attempts at the problem. What you get if you take that
  route is an imposing infrastructure that has virually nothing
  to do and that adds no value to the solution. Programming to the
  LSM interface, on the other hand, allowed me to drastically reduce
  the size and complexity of the implementation.
 
 (tongue-in-cheek)
 
 No no, everyone knows you don't build simpler things on top of more
 complicated ones, you go the other way around.  So what he was
 suggesting was that selinux be re-written on top of smack.
 
 :)

I'm not sure how seriously anyone ought to take what I'm about to
outline. Please feel free to treat it with as much or as little
reverence as you choose.

How to implement SELinux starting from Smack.

You'll need to break up the current rwxa accesses into a set
that matches the current SELinux set. Assign each a letter and
a MAY_ACTION #define.

You'll need a mapping for domain transitions, something like:

 subject-label program-label new-subject-label

This will require bprm hooks that aren't there now.

Additional hooks will need to be filled out as Smack does not
add access control to things that aren't objects or actions that
aren't accesses. Treat these as if they are accesses to objects
and there shouldn't be too much trouble.

Do something about the linear search for subject/object label pairs.
With the larger label set searching will become an issue.

Audit integration, too. The networking code will require some work
for ipsec. The interfaces are pretty clean, Smack isn't using it
because the CIPSO interface is simpler, not because there's any
real problem with it.

I wouldn't expect the whole thing to be more than a couple week's
work for someone who really wanted to do it.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Eric W. Biederman [EMAIL PROTECTED] wrote:

 It really seems to me that the LSM as currently structured creates
 a large barrier to entry for people who have just this little thing
 they want to do that is not possible with any existing security
 module.

I honestly think that the barrier has been more political
in nature than technical. I don't know how long you've been
watching, but no attempt to get an LSM upstream has escaped
exagerated cricism from certain factions. Only someone who wants
to get cut to metaphorical ribbons would submit a little LSM.
Maybe that will get better now. I sure hope so.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Eric W. Biederman [EMAIL PROTECTED] wrote:


 My very practical question:  How do I run selinux in one container,
 and SMACK in another?

How would you run PREEMPT_RT in one container, and PREEMPT_DESKTOP
in another? How would you run SMP in one and UP in the other?
One aspect that SELinux and Smack share is that they only really
provide security if all processes involved are under their control,
just like the preemption behavior.

This is not necessarily true of all possible LSMs. In that case it may
be practicle to have different behavior for different containers.


Casey Schaufler
[EMAIL PROTECTED]
-
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

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Eric W. Biederman [EMAIL PROTECTED] wrote:

 Casey Schaufler [EMAIL PROTECTED] writes:
 
  --- Eric W. Biederman [EMAIL PROTECTED] wrote:
 
 
  Likely.  Until we have a generalized LSM interface with 1000 config
  options like netfilter I don't expect we will have grounds to talk
  or agree to a common user space interface.  Although I could be
  wrong.
 
  Gulp. I know that many of you are granularity advocates, but I
  have to say that security derived by tweeking 1000 knobs so that
  they are all just right seems a little far fetched to me. I see
  it as poopooing the 3rd and most important part of the reference
  monitor concept, small enough to analyze. Sure, you can analyse
  the 1000 individual checks, but you'll never be able to describe
  the system behavior as a whole.
 
 Agreed.  I wasn't thinking 1000 individual checks but 1000 different
 capabilities, could be either checks or actions, basically fundamental
 different capabilities.  Things like CIPSO, or the ability to store a
 security label on a file.  I would not expect most security policies
 to use most of them.  Neither do I expect Orange book security to
 necessarily be what people want to achieve with the LSM.   But I
 haven't looked at it enough detail to know how things should be
 factored, in this case I was simply extrapolating from the iptables
 experience where  we do have a very large number of options.

You start getting into some pretty serious mindset battles on
this particular road. For starters, the hooks have to be
authoritative if you want them properly switchable, and I'm not
going to show you the scars I got the last time I proposed
authoritative hooks. Next you'll have to deal with defining what is
security behavior and what isn't. You wouldn't believe the debates
over the security implications, or lack thereof, of disk quotas.
Unless you're willing to take the approach that every conditional
in the kernel is a potential security checkpoint you are going to
miss someone's requirement and if you're willing to propose that,
well, let's just say that Linus was right about security people.

 The real point being is that I would be surprised if we could come
 to an agreement of a common user space API when we can't agree on how
 to compile all of the security modules into the kernel and have them
 play nice with each other. 

The API issue cannot be solved if LSMs are going to implement
different behaviors. A reasonable subset can be addressed using
the POSIX P1003.1e/2c MAC definition plus the TSIG APIs. It is
unfortunate that SELinux has gone in a completely different
direction.

 Assuming we can achieve security modules playing nice with each other
 using a mechanism similar to iptables, then what needs to be evaluated
 is the specific table configuration we are using on the system, not
 the full general set of possibilities.  Further I expect that for the
 truly security paranoid we want the option to disable further table
 changes after the tables have been configured.

A specific table configuration sounds an awful lot like a
specific SELinux Policy. Either way, your configuration is
going to be large and may not implement anything rational.

 On another side personally I don't see where the idea comes from that
 you can describe system behavior as a whole without analyzing the
 entire kernel.  Has there been work on a sparse like tool that I'm
 not aware of to ensure the we always perform the appropriate security
 checks on the user/kernel interface boundary?

In addition to tools, there's the labor and money intensive Common
Criteria Evaluation Process.


Casey Schaufler
[EMAIL PROTECTED]
-
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

[PATCH] [NetLabel] Introduce a new kernel configuration API for NetLabel - for Smack Version 5

[Casey Schaufler]

From: Paul Moore [EMAIL PROTECTED]

Add a new set of configuration functions to the NetLabel/LSM API so that
LSMs can perform their own configuration of the NetLabel subsystem without
relying on assistance from userspace.

Signed-off-by: Paul Moore [EMAIL PROTECTED]
---

This update fixes a memory leak on error conditions.

 include/net/netlabel.h |   47 --
 net/ipv4/cipso_ipv4.c  |4 -
 net/netlabel/netlabel_cipso_v4.c   |2 
 net/netlabel/netlabel_cipso_v4.h   |3 +
 net/netlabel/netlabel_domainhash.h |1 
 net/netlabel/netlabel_kapi.c   |  177 
 6 files changed, 225 insertions(+), 9 deletions(-)

diff --git a/include/net/netlabel.h b/include/net/netlabel.h
index 2e5b2f6..facaf68 100644
--- a/include/net/netlabel.h
+++ b/include/net/netlabel.h
@@ -36,6 +36,8 @@
 #include net/netlink.h
 #include asm/atomic.h
 
+struct cipso_v4_doi;
+
 /*
  * NetLabel - A management interface for maintaining network packet label
  *mapping tables for explicit packet labling protocols.
@@ -99,12 +101,6 @@ struct netlbl_audit {
uid_t loginuid;
 };
 
-/* Domain mapping definition struct */
-struct netlbl_dom_map;
-
-/* Domain mapping operations */
-int netlbl_domhsh_remove(const char *domain, struct netlbl_audit *audit_info);
-
 /* LSM security attributes */
 struct netlbl_lsm_cache {
atomic_t refcount;
@@ -285,6 +281,19 @@ static inline void netlbl_secattr_free(struct 
netlbl_lsm_secattr *secattr)
 
 #ifdef CONFIG_NETLABEL
 /*
+ * LSM configuration operations
+ */
+int netlbl_cfg_map_del(const char *domain, struct netlbl_audit *audit_info);
+int netlbl_cfg_unlbl_add_map(const char *domain,
+struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+  const char *domain,
+  struct netlbl_audit *audit_info);
+int netlbl_cfg_cipsov4_del(u32 doi, struct netlbl_audit *audit_info);
+
+/*
  * LSM security attribute operations
  */
 int netlbl_secattr_catmap_walk(struct netlbl_lsm_secattr_catmap *catmap,
@@ -318,6 +327,32 @@ void netlbl_cache_invalidate(void);
 int netlbl_cache_add(const struct sk_buff *skb,
 const struct netlbl_lsm_secattr *secattr);
 #else
+static inline int netlbl_cfg_map_del(const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_unlbl_add_map(const char *domain,
+  struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add(struct cipso_v4_doi *doi_def,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_add_map(struct cipso_v4_doi *doi_def,
+const char *domain,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
+static inline int netlbl_cfg_cipsov4_del(u32 doi,
+struct netlbl_audit *audit_info)
+{
+   return -ENOSYS;
+}
 static inline int netlbl_secattr_catmap_walk(
  struct netlbl_lsm_secattr_catmap *catmap,
  u32 offset)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ab56a05..714461c 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -557,8 +557,8 @@ int cipso_v4_doi_remove(u32 doi,
spin_unlock(cipso_v4_doi_list_lock);
list_for_each_entry_rcu(dom_iter, doi_def-dom_list, list)
if (dom_iter-valid)
-   netlbl_domhsh_remove(dom_iter-domain,
-audit_info);
+   netlbl_cfg_map_del(dom_iter-domain,
+  audit_info);
cipso_v4_cache_invalidate();
rcu_read_unlock();
 
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index c060e3f..07f7fd4 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -89,7 +89,7 @@ static const struct nla_policy 
netlbl_cipsov4_genl_policy[NLBL_CIPSOV4_A_MAX + 1
  * safely.
  *
  */
-static void netlbl_cipsov4_doi_free(struct rcu_head *entry)
+void netlbl_cipsov4_doi_free(struct rcu_head *entry)
 {
struct cipso_v4_doi *ptr;
 
diff --git a/net/netlabel/netlabel_cipso_v4.h b/net/netlabel/netlabel_cipso_v4.h
index f03cf9b..220cb9d 100644
--- a/net/netlabel/netlabel_cipso_v4.h
+++ b/net/netlabel/netlabel_cipso_v4.h
@@ -163,4 +163,7 @@ enum {
 /* NetLabel protocol functions */
 int netlbl_cipsov4_genl_init(void);