[GIT PULL] keys bugfix

2015-12-27 Thread James Morris
This is a resend of just the first (critical) fix.

Please pull.


The following changes since commit 8db7b3c54401d83a4dc370a59b8692854000ea03:

  Merge branch 'parisc-4.4-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2015-12-25 
13:19:50 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus2

David Howells (1):
  KEYS: Fix race between read and revoke

 security/keys/keyctl.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

---

commit b4a1b4f5047e4f54e194681125c74c0aa64d637d
Author: David Howells <dhowe...@redhat.com>
Date:   Fri Dec 18 01:34:26 2015 +

KEYS: Fix race between read and revoke

This fixes CVE-2015-7550.

There's a race between keyctl_read() and keyctl_revoke().  If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.

This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.

Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.

I think the bug was introduced with the original keyrings code.

This was discovered by a multithreaded test program generated by syzkaller
(http://github.com/google/syzkaller).  Here's a cleaned up version:

#include 
#include 
#include 
void *thr0(void *arg)
{
key_serial_t key = (unsigned long)arg;
keyctl_revoke(key);
return 0;
}
void *thr1(void *arg)
{
key_serial_t key = (unsigned long)arg;
char buffer[16];
keyctl_read(key, buffer, 16);
return 0;
}
int main()
{
key_serial_t key = add_key("user", "%", "foo", 3, 
KEY_SPEC_USER_KEYRING);
pthread_t th[5];
pthread_create([0], 0, thr0, (void *)(unsigned long)key);
pthread_create([1], 0, thr1, (void *)(unsigned long)key);
pthread_create([2], 0, thr0, (void *)(unsigned long)key);
pthread_create([3], 0, thr1, (void *)(unsigned long)key);
pthread_join(th[0], 0);
pthread_join(th[1], 0);
pthread_join(th[2], 0);
pthread_join(th[3], 0);
return 0;
}

Build as:

cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

Run as:

while keyctl-race; do :; done

as it may need several iterations to crash the kernel.  The crash can be
summarised as:

BUG: unable to handle kernel NULL pointer dereference at 
0010
IP: [] user_read+0x56/0xa3
...
Call Trace:
 [] keyctl_read_key+0xb6/0xd7
 [] SyS_keyctl+0x83/0xe0
 [] entry_SYSCALL_64_fastpath+0x12/0x6f

Reported-by: Dmitry Vyukov <dvyu...@google.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Tested-by: Dmitry Vyukov <dvyu...@google.com>
    Cc: sta...@vger.kernel.org
Signed-off-by: James Morris <james.l.mor...@oracle.com>

diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index fb111ea..1c3872a 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -751,16 +751,16 @@ long keyctl_read_key(key_serial_t keyid, char __user 
*buffer, size_t buflen)
 
/* the key is probably readable - now try to read it */
 can_read_key:
-   ret = key_validate(key);
-   if (ret == 0) {
-   ret = -EOPNOTSUPP;
-   if (key->type->read) {
-   /* read the data with the semaphore held (since we
-* might sleep) */
-   down_read(>sem);
+   ret = -EOPNOTSUPP;
+   if (key->type->read) {
+   /* Read the data with the semaphore held (since we might sleep)
+* to protect against the key being updated or revoked.
+*/
+   down_read(>sem);
+   ret = key_validate(key);
+   if (ret == 0)
ret = key->type->read(key, buffer, buflen);
-   up_read(>sem);
-   }
+   up_read(>sem);
}
 
 error2:

-- 
James Morris
<jmor...@namei.org>

--
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: [GIT PULL] linux-integrity changes for 4.5

2015-12-26 Thread James Morris
On Mon, 21 Dec 2015, Mimi Zohar wrote:

> Hi James,
> 
> Lots of changes this time.  This pull request adds support, by Dmitry
> Kasatkin, for: making the EVM keyring a trusted keyring, such that only
> keys signed by a key on the system keyring can be loaded onto the EVM
> keyring, loading the EVM keys onto the EVM trusted keyring by the
> kernel, enabling EVM when either the x509 or symmetric keys are
> available and loading the EVM symmetric key from hardware.
> 
> As described by Mark Baushke and Petko Manalov at LSS 2015 in their talk
> "IMA/EVM: Real Applications for Embedded Networking Systems", this pull
> request includes support for two new IMA trusted keyrings named .ima_mok
> and .ima_blacklist.  Keys being loaded on either the EVM or IMA trusted
> keyrings can be validated against either the system trusted keyring or
> the intermediary .ima_mok keyring and prevented from being loaded if on
> the .ima_blacklist keyring.
> 
> Lastly, support for extending and displaying the IMA policy.
> 

Applied.

-- 
James Morris
<jmor...@namei.org>

--
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: [PULL] Smack - Changes for 4.5

2015-12-26 Thread James Morris
On Tue, 22 Dec 2015, Casey Schaufler wrote:

> The following changes since commit ebd68df3f24b318d391d15c458d6f43f340ba36a:
> 
>   Sync to Linus v4.4-rc2 for LSM developers. (2015-11-23 22:46:28 +1100)
> 
> are available in the git repository at:
> 
>   https://github.com/cschaufler/smack-next.git smack-for-4.5
> 
> for you to fetch changes up to 81bd0d56298f93af6ac233d8a7e8b29aa4b094b7:
> 
>   Smack: type confusion in smak sendmsg() handler (2015-12-17 10:21:56 -0800)
> 
> 
> Casey Schaufler (1):
>   Smack: File receive for sockets
> 
> Roman Kubiak (1):
>   Smack: type confusion in smak sendmsg() handler
> 
>  security/smack/smack_lsm.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 

Applied.


-- 
James Morris
<jmor...@namei.org>

--
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: [GIT PULL] SELinux patches for 4.5

2015-12-26 Thread James Morris
On Thu, 24 Dec 2015, Paul Moore wrote:

> Hi James,
> 
> Nine patches for v4.5; there are a handful of minor fixes (constify 
> parameters, warning rate-limits, etc.) but there are a couple of significant 
> patches that invalidate/revalidate inode labels (needed for gfs2) and make 
> validate_trans decisions visible via selinuxfs.  All the patches pass the 
> selinux-testsuite and have been included in the pcmoore/kernel-secnext Fedora 
> COPR repository[1] for some time now, all looks good.
> 
> As of about five minutes ago, selinux#upstream applied cleanly on top of 
> linux-security#next so I don't expect you should have any problems merging 
> the 
> code.

Applied.

-- 
James Morris
<jmor...@namei.org>

--
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: [GIT PULL] tpmdd updates for Linux 4.5

2015-12-26 Thread James Morris
On Mon, 21 Dec 2015, Jarkko Sakkinen wrote:

> Hi
> 
> Here are tpmdd updates for Linux 4.5. Sorry I didn't send this already
> last week but I had to hold until I get ack from Peter and Mimi before
> doing anything. Patches are quite well baked for a while now with the
> exception of small fix from Stefan to tpm_ibmvtpm, which I considered
> trivial enough to be included.
> 

Applied.

-- 
James Morris
<jmor...@namei.org>

--
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: [GIT PULL] Keys fixes

2015-12-18 Thread James Morris
On Fri, 18 Dec 2015, Linus Torvalds wrote:

> So there is no way in hell I am pulling this.
> 

Sorry for the confusion.

Please pull the first patch from here:

The following changes since commit 73796d8bf27372e26c2b79881947304c14c2d353:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-12-17 
14:05:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus2

David Howells (1):
  KEYS: Fix race between read and revoke

---

 security/keys/keyctl.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)
commit b4a1b4f5047e4f54e194681125c74c0aa64d637d
Author: David Howells <dhowe...@redhat.com>
Date:   Fri Dec 18 01:34:26 2015 +

KEYS: Fix race between read and revoke

This fixes CVE-2015-7550.

There's a race between keyctl_read() and keyctl_revoke().  If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.

This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.

Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.

I think the bug was introduced with the original keyrings code.

This was discovered by a multithreaded test program generated by syzkaller
(http://github.com/google/syzkaller).  Here's a cleaned up version:

#include 
#include 
#include 
void *thr0(void *arg)
{
key_serial_t key = (unsigned long)arg;
keyctl_revoke(key);
return 0;
}
void *thr1(void *arg)
{
key_serial_t key = (unsigned long)arg;
char buffer[16];
keyctl_read(key, buffer, 16);
return 0;
}
int main()
{
key_serial_t key = add_key("user", "%", "foo", 3, 
KEY_SPEC_USER_KEYRING);
pthread_t th[5];
pthread_create([0], 0, thr0, (void *)(unsigned long)key);
pthread_create([1], 0, thr1, (void *)(unsigned long)key);
pthread_create([2], 0, thr0, (void *)(unsigned long)key);
pthread_create([3], 0, thr1, (void *)(unsigned long)key);
pthread_join(th[0], 0);
pthread_join(th[1], 0);
pthread_join(th[2], 0);
pthread_join(th[3], 0);
return 0;
}

Build as:

cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread

Run as:

while keyctl-race; do :; done

as it may need several iterations to crash the kernel.  The crash can be
summarised as:

BUG: unable to handle kernel NULL pointer dereference at 
0010
IP: [] user_read+0x56/0xa3
...
Call Trace:
 [] keyctl_read_key+0xb6/0xd7
 [] SyS_keyctl+0x83/0xe0
 [] entry_SYSCALL_64_fastpath+0x12/0x6f

Reported-by: Dmitry Vyukov <dvyu...@google.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Tested-by: Dmitry Vyukov <dvyu...@google.com>
    Cc: sta...@vger.kernel.org
Signed-off-by: James Morris <james.l.mor...@oracle.com>

diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index fb111ea..1c3872a 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -751,16 +751,16 @@ long keyctl_read_key(key_serial_t keyid, char __user 
*buffer, size_t buflen)
 
/* the key is probably readable - now try to read it */
 can_read_key:
-   ret = key_validate(key);
-   if (ret == 0) {
-   ret = -EOPNOTSUPP;
-   if (key->type->read) {
-   /* read the data with the semaphore held (since we
-* might sleep) */
-   down_read(>sem);
+   ret = -EOPNOTSUPP;
+   if (key->type->read) {
+   /* Read the data with the semaphore held (since we might sleep)
+* to protect against the key being updated or revoked.
+*/
+   down_read(>sem);
+   ret = key_validate(key);
+   if (ret == 0)
ret = key->type->read(key, buffer, buflen);
-   up_read(>sem);
-   }
+   up_read(>sem);
}
 
 error2:
--
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


[GIT PULL] Keys fixes

2015-12-17 Thread James Morris
Please pull these fixes for the keys subsystem, including a fix for 
CVE-2015-7550.


The following changes since commit 73796d8bf27372e26c2b79881947304c14c2d353:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-12-17 
14:05:22 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

David Howells (7):
  KEYS: Fix race between read and revoke
  X.509: Fix determination of self-signedness
  X.509: Fix leap year handling again
  Handle leap seconds in mktime64()
  X.509: Support leap seconds
  Handle both ISO 8601 encodings of midnight in mktime64()
  X.509: Handle midnight alternative notation in GeneralizedTime

 crypto/asymmetric_keys/x509_cert_parser.c |   24 +---
 crypto/asymmetric_keys/x509_public_key.c  |   11 ---
 include/linux/time.h  |   13 ++---
 kernel/time/time.c|   19 +++
 security/keys/keyctl.c|   18 +-
 5 files changed, 55 insertions(+), 30 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 2/2] keys, trusted: seal with a policy

2015-12-07 Thread James Morris
On Mon, 7 Dec 2015, Jarkko Sakkinen wrote:

> On Fri, Nov 20, 2015 at 01:34:35PM +1100, James Morris wrote:
> > On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:
> > 
> > > On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > > > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > > > 
> > > > >   }
> > > > >   break;
> > > > > + case Opt_policydigest:
> > > > > + if (!tpm2 ||
> > > > > + strlen(args[0].from) != (2 * 
> > > > > opt->digest_len))
> > > > > + return -EINVAL;
> > > > > + kfree(opt->policydigest);
> > > > > + opt->policydigest = kzalloc(opt->digest_len,
> > > > > + GFP_KERNEL);
> > > > 
> > > > Is it correct to kfree opt->policydigest here before allocating it?
> > > 
> > > I think so. The same option might be encountered multiple times.
> > 
> > This would surely signify an error?
> 
> I'm following the semantics of other options. That's why I implemented
> it that way for example:
> 
> keyctl add trusted kmk "new 32 keyhandle=0x8000 keyhandle=0x8000"
> 
> is perfectly OK. I just thought that it'd be more odd if this option
> behaved in a different way...

It seems broken to me -- if you're messing up keyctl commands you might 
want to know about it, but we should remain consistent.


-- 
James Morris
<jmor...@namei.org>

--
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] KEYS: Fix handling of stored error in a negatively instantiated user key

2015-11-24 Thread James Morris
On Tue, 24 Nov 2015, David Howells wrote:

> Hi James,
> 
> Can this be passed straight to Linus please?

Is this triggerable by normal users?


-- 
James Morris
<jmor...@namei.org>

--
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] keys, trusted: seal with a policy

2015-11-19 Thread James Morris
On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:

> On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > 
> > >   }
> > >   break;
> > > + case Opt_policydigest:
> > > + if (!tpm2 ||
> > > + strlen(args[0].from) != (2 * opt->digest_len))
> > > + return -EINVAL;
> > > + kfree(opt->policydigest);
> > > + opt->policydigest = kzalloc(opt->digest_len,
> > > + GFP_KERNEL);
> > 
> > Is it correct to kfree opt->policydigest here before allocating it?
> 
> I think so. The same option might be encountered multiple times.

This would surely signify an error?


-- 
James Morris
<jmor...@namei.org>

--
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 v3 0/7] User namespace mount updates

2015-11-18 Thread James Morris
On Wed, 18 Nov 2015, Richard Weinberger wrote:

> On Wed, Nov 18, 2015 at 4:13 PM, Al Viro <v...@zeniv.linux.org.uk> wrote:
> > On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote:
> >
> >> Yes, the host admin. I'm not talking about trusting the admin inside the
> >> container at all.
> >
> > Then why not have the same host admin just plain mount it when setting the
> > container up and be done with that?  From the host namespace, before 
> > spawning
> > the docker instance or whatever framework you are using.  IDGI...
> 
> Because hosting companies sell containers as "full virtual machines"
> and customers expect to be able mount stuff like disk images they upload.

I don't think this is a valid reason for merging functionality into the 
kernel.


-- 
James Morris
<jmor...@namei.org>

--
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] security/capability.h: cap_issubset/isclear can be boolean

2015-11-17 Thread James Morris
On Tue, 17 Nov 2015, Yaowei Bai wrote:

> This patch makes cap_issubset/isclear return bool due to these
> functions only using either one or zero as their return
> value.
> 
> No functional change.
> 
> Signed-off-by: Yaowei Bai <baiyao...@cmss.chinamobile.com>

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris
<jmor...@namei.org>

--
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 1/2] security: remove unused cap_is_fs_cap function

2015-11-17 Thread James Morris
On Tue, 17 Nov 2015, Yaowei Bai wrote:

> Since commit 3bc1fa8a ("LSM: remove BSD secure level security module")
> there is no user of cap_is_fs_cap any more, so remove it.
> 
> Signed-off-by: Yaowei Bai <baiyao...@cmss.chinamobile.com>

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

-- 
James Morris
<jmor...@namei.org>

--
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 v3 5/7] selinux: Add support for unprivileged mounts from user namespaces

2015-11-17 Thread James Morris
On Tue, 17 Nov 2015, Seth Forshee wrote:

> Security labels from unprivileged mounts in user namespaces must
> be ignored. Force superblocks from user namespaces whose labeling
> behavior is to use xattrs to use mountpoint labeling instead.
> For the mountpoint label, default to converting the current task
> context into a form suitable for file objects, but also allow the
> policy writer to specify a different label through policy
> transition rules.
> 
> Pieced together from code snippets provided by Stephen Smalley.
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>
> Acked-by: Stephen Smalley <s...@tycho.nsa.gov>


Acked-by: James Morris <james.l.mor...@oracle.com>

-- 
James Morris
<jmor...@namei.org>

--
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 v3 6/7] userns: Replace in_userns with current_in_userns

2015-11-17 Thread James Morris
On Tue, 17 Nov 2015, Seth Forshee wrote:

> All current callers of in_userns pass current_user_ns as the
> first argument. Simplify by replacing in_userns with
> current_in_userns which checks whether current_user_ns is in the
> namespace supplied as an argument.
> 
> Signed-off-by: Seth Forshee <seth.fors...@canonical.com>

Nice cleanup.


Acked-by: James Morris <james.l.mor...@oracle.com>

-- 
James Morris
<jmor...@namei.org>

--
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


[GIT PULL] Security subsystem bugfixes for 4.4

2015-11-12 Thread James Morris
This includes several fixes for TPM, as well as a fix for the x.509 
certificate parser to address CVE-2015-5327.

Please pull.

---

The following changes since commit 5d50ac70fe98518dbf620bfba8184254663125eb:

  Merge tag 'xfs-for-linus-4.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs (2015-11-11 
20:18:48 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

Christophe JAILLET (1):
  TPM: Avoid reference to potentially freed memory

David Howells (1):
  X.509: Fix the time validation [ver #2]

James Morris (1):
  Merge tag 'tpmdd-next-20151110' of 
https://github.com/jsakkine/linux-tpmdd into for-linus

Jarkko Sakkinen (3):
  TPM: revert the list handling logic fixed in 398a1e7
  tpm: fix missing migratable flag in sealing functionality for TPM2
  tpm: fix compat 'ppi' link handling in tpm_chip_register()

Martin Wilck (2):
  tpm_tis: free irq after probing
  tpm_tis: restore IRQ vector in IO memory after failed probing

 crypto/asymmetric_keys/x509_cert_parser.c |   12 +++-
 drivers/char/tpm/tpm-chip.c   |   20 +++-
 drivers/char/tpm/tpm2-cmd.c   |   15 ++-
 drivers/char/tpm/tpm_of.c |3 ++-
 drivers/char/tpm/tpm_tis.c|8 +++-
 5 files changed, 37 insertions(+), 21 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] X.509: Fix the time validation

2015-11-12 Thread James Morris
On Wed, 11 Nov 2015, David Howells wrote:

> This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.

This doesn't apply to current Linus, please fix and resend.

-- 
James Morris
<jmor...@namei.org>

--
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] keys, trusted: select hash algorithm for TPM2 chips

2015-11-09 Thread James Morris
On Thu, 5 Nov 2015, Jarkko Sakkinen wrote:

> v4:
> 
> * Added missing select CRYPTO_HASH_INFO in drivers/char/tpm/Kconfig
> 
> Signed-off-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>


Reviewed-by: James Morris <james.l.mor...@oracle.com>


-- 
James Morris
<jmor...@namei.org>

--
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


[GIT PULL] Security subsystem update for 4.4

2015-11-03 Thread James Morris
Please pull.

This is mostly maintenance updates across the subsystem, with a notable 
update for TPM 2.0, and addition of Jarkko Sakkinen as a maintainer of 
that.

The following changes since commit 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c:

  Merge tag 'regmap-v4.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap (2015-11-02 
16:16:24 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

Arnd Bergmann (1):
  apparmor: clarify CRYPTO dependency

David Howells (3):
  KEYS: Provide a script to extract the sys cert list from a vmlinux file
  KEYS: Provide a script to extract a module signature
  KEYS: Merge the type-specific data with the payload data

Dmitry Kasatkin (1):
  integrity: prevent loading untrusted certificates on the IMA trusted 
keyring

Geert Uytterhoeven (1):
  tpm: Allow compile test of GPIO consumers if !GPIOLIB

Geliang Tang (3):
  smack: smk_ipv6_port_list should be static
  KEYS: use kvfree() in add_key
  selinux: ioctl_has_perm should be static

Hon Ching \(Vicky\) Lo (6):
  vTPM: fix memory allocation flag for rtce buffer at kernel boot
  vTPM: fix searching for the right vTPM node in device tree
  vTPM: reformat event log to be byte-aligned
  vTPM: get the buffer allocated for event log instead of the actual log
  vTPM: support little endian guests
  TPM: remove unnecessary little endian conversion

Insu Yun (1):
  keys: Be more consistent in selection of union members used

James Morris (4):
  Merge branch 'next' of git://git.kernel.org/.../zohar/linux-integrity 
into next
  Merge branch 'smack-for-4.4' of https://github.com/cschaufler/smack-next 
into next
  Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/selinux 
into next
  Merge tag 'keys-next-20151021' of 
git://git.kernel.org/.../dhowells/linux-fs into next

Jarkko Sakkinen (10):
  tpm, tpm_crb: fix unaligned read of the command buffer address
  tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
  sysfs: added __compat_only_sysfs_link_entry_to_kobj()
  tpm: move the PPI attributes to character device directory.
  tpm: update PPI documentation to address the location change.
  tpm: introduce tpm_buf
  keys, trusted: move struct trusted_key_options to trusted-type.h
  tpm: seal/unseal for TPM 2.0
  keys, trusted: seal/unseal with TPM 2.0 chips
  MAINTAINERS: add new maintainer for TPM DEVICE DRIVER

Jeff Vander Stoep (1):
  selinux: do not check open perm on ftruncate call

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

Krzysztof Kozlowski (1):
  char: Drop owner assignment from i2c_driver

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

Paul Gortmaker (1):
  certs: add .gitignore to stop git nagging about x509_certificate_list

Paul Moore (1):
  selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default

Rasmus Villemoes (5):
  selinux: introduce security_context_str_to_sid
  selinux: remove pointless cast in selinux_inode_setsecurity()
  selinux: use kmemdup in security_sid_to_context_core()
  selinux: use kstrdup() in security_get_bools()
  selinux: use sprintf return value

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

Sangwoo (1):
  selinux: Use a kmem_cache for allocation struct file_security_struct

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

 Documentation/ABI/testing/sysfs-driver-ppi   |   19 +-
 Documentation/crypto/asymmetric-keys.txt |   27 ++--
 Documentation/security/Smack.txt |   10 +
 Documentation/security/keys.txt  |   41 +++--
 MAINTAINERS  |1 +
 arch/powerpc/kernel/prom_init.c  |   40 +++-
 certs/.gitignore |4 +
 crypto/asymmetric_keys/asymmetric_keys.h |5 -
 crypto/asymmetric_keys/asymmetric_type.c |   44 +++--
 crypto/asymmetric_keys/public_key.c  |4 +-
 crypto/asymmetric_keys/signature.c   |2 +-
 crypto/asymmetric_keys/x509_parser.h |1 +
 crypto/asymmetric_keys/x509_public_key.c |9 +-
 drivers/char/tpm/st33zp24/Kconfig|2 +-
 drivers/char/tpm/st33zp24/i2c.c  |1 -
 drivers/char/tpm/tpm-chip.c  |   24 ++-
 drivers/char/tpm/tpm-interface.c |   76 +++
 drivers/char/tpm/tpm.h   |  134 +++-
 drivers/char/tpm/tpm2-cmd.c  |  250 +-
 drivers/char/tpm/tpm_crb.c   |   39 ++--
 drivers/char/tpm/tpm_eventlog.c  |   78 +--
 drivers/char/tpm/tpm_eventlog.h  |6 +
 drivers/char/tpm/tpm_i2c_atmel.c

Re: [GIT PULL] KEYS: Miscellaneous patches for next

2015-10-22 Thread James Morris
On Thu, 22 Oct 2015, David Howells wrote:

> Hi James,
> 
> Could you pull these changes into your next branch please?
> 
> There are three groups:
> 
>  (1) Miscellaneous cleanups.
> 
>  (2) Add scripts for extracting system cert list and module sigs.
> 
>  (3) Condense the type-specific data in the key struct into the payload
>  data as it doesn't really make any sense to keep them separate.
> 

Pulled.

Have these been in next yet?


-- 
James Morris
<jmor...@namei.org>

--
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 v5 0/3] RFC: Secure Memory Allocation Framework

2015-10-21 Thread James Morris
On Wed, 21 Oct 2015, Benjamin Gaignard wrote:

> 
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
> 

Have you addressed all the questions raised by Alan here:

https://lkml.org/lkml/2015/5/8/629

Also, is there any application of this beyond DRM?


- James
-- 
James Morris
<jmor...@namei.org>

--
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 v5 1/3] create SMAF module

2015-10-21 Thread James Morris
On Wed, 21 Oct 2015, Benjamin Gaignard wrote:

> Secure Memory Allocation Framework goal is to be able
> to allocate memory that can be securing.
> There is so much ways to allocate and securing memory that SMAF
> doesn't do it by itself but need help of additional modules.
> To be sure to use the correct allocation method SMAF implement
> deferred allocation (i.e. allocate memory when only really needed)
> 
> Allocation modules (smaf-alloctor.h):
> SMAF could manage with multiple allocation modules at same time.
> To select the good one SMAF call match() to be sure that a module
> can allocate memory for a given list of devices. It is to the module
> to check if the devices are compatible or not with it allocation
> method.
> 
> Securing module (smaf-secure.h):
> The way of how securing memory it is done is platform specific.
> Secure module is responsible of grant/revoke memory access.
> 

This documentation is highly inadequate.

What does "allocate memory that can be securing" mean?


-- 
James Morris
<jmor...@namei.org>

--
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: [GIT PULL] SELinux patches for 4.4

2015-10-21 Thread James Morris
On Wed, 21 Oct 2015, Paul Moore wrote:

> Hi James,
> 
> Nine SELinux patches in total for v4.4, although six of those patches are 
> either trivial, minor cleanups, or both.  The remaining three patches aren't 
> too bad: one changes the CHECKREQPROT default to check the actual memory 
> protections, one stops us from checking file:open on ftruncate() calls, and 
> one converts the file_security_struct over to kmem_cache.
> 
> All pass the SELinux testsuite and should apply cleanly on top of your next 
> branch.
> 

Pulled, thanks.


-- 
James Morris
<jmor...@namei.org>

--
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] apparmor: clarify CRYPTO dependency

2015-10-21 Thread James Morris
On Wed, 21 Oct 2015, Arnd Bergmann wrote:

> The crypto framework can be built as a loadable module, but the
> apparmor hash code can only be built-in, which then causes a
> link error:
> 
> security/built-in.o: In function `aa_calc_profile_hash':
> integrity_audit.c:(.text+0x21610): undefined reference to 
> `crypto_shash_update'
> security/built-in.o: In function `init_profile_hash':
> integrity_audit.c:(.init.text+0xb4c): undefined reference to 
> `crypto_alloc_shash'
> 
> This changes Apparmor to use 'select CRYPTO' like a lot of other
> subsystems do.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris
<jmor...@namei.org>

--
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: [PULL] Smack - Changes for 4.4

2015-10-20 Thread James Morris
On Mon, 19 Oct 2015, Casey Schaufler wrote:

> 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
> 

Pulled, thanks.

-- 
James Morris
<jmor...@namei.org>

--
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


[GIT PULL] Keys bugfixes

2015-10-19 Thread James Morris
Please pull these key susbystem fixes for 4.3, per the message from David 
Howells:

"Here are two patches, the first of which at least should go upstream
immediately:

 (1) Prevent a user-triggerable crash in the keyrings destructor when a
 negatively instantiated keyring is garbage collected.  I have also 
 seen this triggered for user type keys.

 (2) Prevent the user from using requesting that a keyring be created and
 instantiated through an upcall.  Doing so is probably safe since the 
 keyring type ignores the arguments to its instantiation function - 
 but we probably shouldn't let keyrings be created in this manner."

---

The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 
09:55:40 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

David Howells (2):
  KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring
  KEYS: Don't permit request_key() to construct a new keyring

 security/keys/gc.c  |6 --
 security/keys/request_key.c |3 +++
 2 files changed, 7 insertions(+), 2 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: [PULL REQUEST] IMA changes for 4.4

2015-10-19 Thread James Morris
On Mon, 19 Oct 2015, Mimi Zohar wrote:

> Hi James,
> 
> This pull request is for a single bug fix from Dimtry to properly load
> only signed certificates onto the trusted IMA keyring from the kernel.
> (This patch has been in the linux-next tree).
> 
> thanks,
> 
> Mimi
> 
> The following changes since commit
> 049e6dde7e57f0054fdc49102e7ef4830c698b46:
> 
>   Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)
> 
> are available in the git repository at:
> 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> next
> 

Pulled, thanks.

-- 
James Morris
<jmor...@namei.org>

--
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: Will you be updating security#next for 4.4?

2015-10-06 Thread James Morris
On Mon, 5 Oct 2015, Casey Schaufler wrote:

> Hi James. I'm starting my patch processing for 4.4 and wondered
> if you're planning to update security#next any time soon.
> 

Now merged to -rc4.

-- 
James Morris
<jmor...@namei.org>

--
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: NFS/LSM: allow NFS to control all of its own mount options

2008-02-19 Thread James Morris
On Tue, 19 Feb 2008, Christoph Hellwig wrote:

 Please don't introduce a special case for just nfs.  All filesystems
 should control their mount options, so please provide some library
 helpers for context= handling and move it into all filesystems that
 can support selinux.

It's not so much a special case for NFS, just that NFS happens to use 
binary mount options.  So, I guess it could be put into a library for 
other potential filesystems with binary mount options.

To clarify:

The SELinux options are indeed filesystem independent, and the FS should 
really not need to be concerned at all with them.  For everything except 
NFS, we parse text options looking for context=, then use that value from 
within SELinux as the label for all files in the mount.

Previously, as Eric mentions, we were using a method initially approved by 
the NFS folk, where, for NFS, SELinux was peeking around inside the binary 
options.  We were then asked to change that so that NFS (or other 
binary-option FS) would obtain the values itself and call into LSM with 
them.  This is what Eric's latest patch enables (a previous patch 
installed the infrastructure for it).

While this code could be put into a library if desired, there is no need 
to make any changes for filesystems with text options (i.e. the general 
case).



- James
-- 
James Morris
[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

2008-02-11 Thread James Morris
On Fri, 8 Feb 2008, David Howells 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.

...

These patches are kind of huge.

 +static int selinux_task_dup_security(struct task_security *sec)
 +{
 + struct task_security_struct *tsec1, *tsec2;
 +
 + tsec1 = sec-security;
 +
 + tsec2 = kmemdup(tsec1, sizeof(*tsec1), GFP_KERNEL);
 + if (!tsec2)
 + return -ENOMEM;
 +
 + tsec2-osid = tsec1-osid;
 + tsec2-sid = tsec1-sid;
 +
 + tsec2-exec_sid = tsec1-exec_sid;
 + tsec2-create_sid = tsec1-create_sid;
 + tsec2-keycreate_sid = tsec1-keycreate_sid;
 + tsec2-sockcreate_sid = tsec1-sockcreate_sid;
 + tsec2-ptrace_sid = SECINITSID_UNLABELED;
 + sec-security = tsec2;
 +
 + return 0;
  }

Why manually copy these fields after a kmemdup?

What about the task backpointer? (i.e. tsec2-task)


-- 
James Morris
[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 05/37] Security: Change current-fs[ug]id to current_fs[ug]id()

2008-02-11 Thread James Morris
On Fri, 8 Feb 2008, David Howells wrote:

 Change current-fs[ug]id to current_fs[ug]id() so that fsgid and fsuid can be
 separated from the task_struct.
 
 Signed-off-by: David Howells [EMAIL PROTECTED]

Reviewed-by: James Morris [EMAIL PROTECTED]


-- 
James Morris
[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 06/37] Security: Separate task security context from task_struct

2008-02-11 Thread James Morris
On Fri, 8 Feb 2008, David Howells wrote:

 Separate the task security context from task_struct.  At this point, the
 security data is temporarily embedded in the task_struct with two pointers
 pointing to it.
 
 Alpha needs further alteration as it refers to UID  GID in entry.S via asm
 offsets.
 
 Sparc needs further alteration as it refers to UID  GID in sclow.S via asm
 offsets.
 
 Signed-off-by: David Howells [EMAIL PROTECTED]

Reviewed-by: James Morris [EMAIL PROTECTED]

(SELinux stuff mostly).

-- 
James Morris
[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] security: add iptables security table for MAC rules

2008-01-29 Thread James Morris
On Tue, 29 Jan 2008, Paul Moore wrote:

 That seems reasonable.  By the way, this isn't really related, but is it 
 possible to change the NF_IP_PRI_SELINUX_* constants to NF_IP_PRI_SECURITY_* 
 for the sake of consistency or are those values already visible to userspace? 
  

They are visible to userspace, and included in glibc headers, but I don't 
see any userland use of them via google codesearch or know of a possible 
valid use.

 I suppose we could always rename them anyway and just add a #define for 
 compatibility ...

Yep, if you want to.


- James
-- 
James Morris
[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: Default Linux Capabilities default in 2.6.24

2008-01-28 Thread James Morris
On Mon, 28 Jan 2008, Matt LaPlante wrote:

 On Thu, 24 Jan 2008 19:12:01 -0600
 Matt LaPlante [EMAIL PROTECTED] wrote:
 
  
  I'm doing a make oldconfig with the new 2.6.24 kernel.  I came to the 
  prompt for Default Linux Capabilities which defaults to No:
  
  ---
   Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ?
  ---
  
  However the help text recommends saying Yes.
  
  ---
   This enables the default Linux capabilities functionality.
   If you are unsure how to answer this question, answer Y.
  ---
  
  Does this seem incongruous?  Also, what's the question? :)
  
  Thanks, 
  Matt LaPlante
 
 Anyone?

I think this should be default y.


-- 
James Morris
[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]

2008-01-23 Thread James Morris
On Wed, 23 Jan 2008, David Howells wrote:

 Stephen Smalley [EMAIL PROTECTED] wrote:
 
  Make sure that you or Dan submits a policy patch to register these
  classes and permissions in the policy when the kernel patch is queued
  for merge.
 
 Do I just send the attached patch to [EMAIL PROTECTED]?  

That should be enough (and that list is on the cc).

Or do I need to
 make a diff from a point in the tree nearer the root?  Is there anything else
 I need to alter whilst I'm at it?
 
 David
 ---
 Index: policy/flask/security_classes
 ===
 --- policy/flask/security_classes (revision 2573)
 +++ policy/flask/security_classes (working copy)
 @@ -109,4 +109,7 @@
  # network peer labels
  class peer
  
 +# kernel services that need to override task security
 +class kernel_service
 +
  # FLASK
 Index: policy/flask/access_vectors
 ===
 --- policy/flask/access_vectors   (revision 2573)
 +++ policy/flask/access_vectors   (working copy)
 @@ -736,3 +736,10 @@
  {
   recv
  }
 +
 +# kernel services that need to override task security
 +class kernel_service
 +{
 + use_as_override
 + create_files_as
 +}
 -
 To unsubscribe from this list: send the line unsubscribe 
 linux-security-module in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe 
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/26] Permit filesystem local caching

2008-01-15 Thread James Morris
On Tue, 15 Jan 2008, David Howells wrote:

 The SELinux base code will also need updating to have the security class, lest
 the following error appear in dmesg:
 
   context_struct_compute_av:  unrecognized class 69

Alternately, what's needed is a newer policy which supports unknown 
permission classes.  Any recent distro policy should have this.


- James
-- 
James Morris
[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] security: call security_file_permission from rw_verify_area

2008-01-12 Thread James Morris
Please review.  

Tested with SELinux in enforcing mode.

---

All instances of rw_verify_area() are followed by a call to
security_file_permission(), so just call the latter from the former.

Signed-off-by: James Morris [EMAIL PROTECTED]
---
 fs/compat.c |4 ---
 fs/read_write.c |   63 +--
 fs/splice.c |8 ---
 3 files changed, 24 insertions(+), 51 deletions(-)

diff --git a/fs/compat.c b/fs/compat.c
index 15078ce..5216c3f 100644
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -1104,10 +1104,6 @@ static ssize_t compat_do_readv_writev(int type, struct 
file *file,
if (ret  0)
goto out;
 
-   ret = security_file_permission(file, type == READ ? MAY_READ:MAY_WRITE);
-   if (ret)
-   goto out;
-
fnv = NULL;
if (type == READ) {
fn = file-f_op-read;
diff --git a/fs/read_write.c b/fs/read_write.c
index ea1f94c..c4d3d17 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -197,25 +197,27 @@ int rw_verify_area(int read_write, struct file *file, 
loff_t *ppos, size_t count
 {
struct inode *inode;
loff_t pos;
+   int retval = -EINVAL;
 
inode = file-f_path.dentry-d_inode;
if (unlikely((ssize_t) count  0))
-   goto Einval;
+   return retval;
pos = *ppos;
if (unlikely((pos  0) || (loff_t) (pos + count)  0))
-   goto Einval;
+   return retval;
 
if (unlikely(inode-i_flock  mandatory_lock(inode))) {
-   int retval = locks_mandatory_area(
+   retval = locks_mandatory_area(
read_write == READ ? FLOCK_VERIFY_READ : 
FLOCK_VERIFY_WRITE,
inode, file, pos, count);
if (retval  0)
return retval;
}
+   retval = security_file_permission(file,
+   read_write == READ ? MAY_READ : MAY_WRITE);
+   if (retval)
+   return retval;
return count  MAX_RW_COUNT ? MAX_RW_COUNT : count;
-
-Einval:
-   return -EINVAL;
 }
 
 static void wait_on_retry_sync_kiocb(struct kiocb *iocb)
@@ -267,18 +269,15 @@ ssize_t vfs_read(struct file *file, char __user *buf, 
size_t count, loff_t *pos)
ret = rw_verify_area(READ, file, pos, count);
if (ret = 0) {
count = ret;
-   ret = security_file_permission (file, MAY_READ);
-   if (!ret) {
-   if (file-f_op-read)
-   ret = file-f_op-read(file, buf, count, pos);
-   else
-   ret = do_sync_read(file, buf, count, pos);
-   if (ret  0) {
-   fsnotify_access(file-f_path.dentry);
-   add_rchar(current, ret);
-   }
-   inc_syscr(current);
+   if (file-f_op-read)
+   ret = file-f_op-read(file, buf, count, pos);
+   else
+   ret = do_sync_read(file, buf, count, pos);
+   if (ret  0) {
+   fsnotify_access(file-f_path.dentry);
+   add_rchar(current, ret);
}
+   inc_syscr(current);
}
 
return ret;
@@ -325,18 +324,15 @@ ssize_t vfs_write(struct file *file, const char __user 
*buf, size_t count, loff_
ret = rw_verify_area(WRITE, file, pos, count);
if (ret = 0) {
count = ret;
-   ret = security_file_permission (file, MAY_WRITE);
-   if (!ret) {
-   if (file-f_op-write)
-   ret = file-f_op-write(file, buf, count, pos);
-   else
-   ret = do_sync_write(file, buf, count, pos);
-   if (ret  0) {
-   fsnotify_modify(file-f_path.dentry);
-   add_wchar(current, ret);
-   }
-   inc_syscw(current);
+   if (file-f_op-write)
+   ret = file-f_op-write(file, buf, count, pos);
+   else
+   ret = do_sync_write(file, buf, count, pos);
+   if (ret  0) {
+   fsnotify_modify(file-f_path.dentry);
+   add_wchar(current, ret);
}
+   inc_syscw(current);
}
 
return ret;
@@ -603,9 +599,6 @@ static ssize_t do_readv_writev(int type, struct file *file,
ret = rw_verify_area(type, file, pos, tot_len);
if (ret  0)
goto out;
-   ret = security_file_permission(file, type == READ ? MAY_READ : 
MAY_WRITE);
-   if (ret)
-   goto out;
 
fnv = NULL;
if (type == READ) {
@@ -737,10 +730,6 @@ static ssize_t do_sendfile(int out_fd, int in_fd

Re: [TOMOYO #6 retry 08/21] Utility functions and policy manipulationinterface.

2008-01-11 Thread James Morris
On Sat, 12 Jan 2008, Tetsuo Handa wrote:

 Hello.
 
 James Morris wrote:
TOMOYO Linux uses /sys/kernel/security/tomoyo interface for 
configuration.
   
   Why aren't you using securityfs for this?  (It was designed for LSMs).
  
  Doh, it is using securityfs, don't worry.
  
 I got a mm-commits mail titled
 + sysfs-make-sysfs_deprecated-depend-on-sysfs.patch added to -mm tree .
 
 Is sysfs going to be deprecated?

Unlikely -- what's in the patches?


- James
-- 
James Morris
[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] Adding prctl override support for LSMs

2008-01-10 Thread James Morris
On Wed, 9 Jan 2008, Andrew Morgan wrote:

 So far the objection (thanks Stephen for the historical context!) seems
 to be potential for abuse:
 
 ~  [EMAIL PROTECTED]
   [PATCH] remove sys_security
 
   I've been auditing the LSM stuff a bit more..
 
   They have registered an implemented a syscall, sys_security
   that does nothing but switch into the individual modules
   based on the first argument, i.e. it's ioctl() switching
   on the security module instead of device node.  Yuck.
 
   Patch below removes it (no intree users), maybe selinux/etc
   folks should send their actual syscall for review instead..
 
 Since SELinux is now 'in-tree', is this class of objection now moot?

Class of objection to a sys_security, or to the prctl override?

If the former, I think it would still be considered a poor option, as 
multiplexor syscalls are generally seen as such for several reasons.  I 
don't think SELinux would need to use it now if it came back.

As Stephen mentioned, the prctl override might also be seen as a means to 
revector/hijack the syscall.

I should mention that I'm still not clear on why you need to have a 
permissive version of this hook.


- James
-- 
James Morris
[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: [TOMOYO #6 retry 08/21] Utility functions and policy manipulation interface.

2008-01-08 Thread James Morris
On Wed, 9 Jan 2008, Kentaro Takeda wrote:

 Common functions for TOMOYO Linux.
 
 TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration.

Why aren't you using securityfs for this?  (It was designed for LSMs).


- James
-- 
James Morris
[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: [TOMOYO #6 retry 08/21] Utility functions and policy manipulation interface.

2008-01-08 Thread James Morris
On Wed, 9 Jan 2008, James Morris wrote:

 On Wed, 9 Jan 2008, Kentaro Takeda wrote:
 
  Common functions for TOMOYO Linux.
  
  TOMOYO Linux uses /sys/kernel/security/tomoyo interface for configuration.
 
 Why aren't you using securityfs for this?  (It was designed for LSMs).

Doh, it is using securityfs, don't worry.


-- 
James Morris
[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] Exporting capability code/name pairs

2008-01-02 Thread James Morris
On Wed, 2 Jan 2008, KaiGai Kohei wrote:

  Another issue is that securityfs depends on CONFIG_SECURITY, which might be
  undesirable, given that capabilities are a standard feature.
 
 We can implement this feature on another pseudo filesystems.
 Do you think what filesystem is the best candidate?
 I prefer procfs or sysfs instead.

Sysfs makes more sense, as this information is system-wide and does not 
relate to specific processes.


-- 
James Morris
[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] Exporting capability code/name pairs

2007-12-28 Thread James Morris
On Fri, 28 Dec 2007, KaiGai Kohei wrote:

 Remaining issues:
 - We have to mount securityfs explicitly, or use /etc/fstab.
   It can cause a matter when we want to use this feature on
   very early phase on boot. (like /sbin/init)

Why can't early userspace itself mount securityfs?

I'm not even sure this is a good idea at all.  Existing capabilities will 
never disappear, and, as with syscalls, it's probably up to userland to 
handle new ones not existing.

In any case, some more technical issues:

 kernel/cap_names.sh generates the body of cap_entries[] array,

This needs to be in the scripts directory.

The generated header should be made idempotent (#ifdef wrapping), and also 
include a warning that it is automatically generated (identifying the 
script which does so), and that is should not be edited.

 + d_caps = securityfs_create_dir(capability, NULL);
 + if (!d_caps)

Wrong way to check for error -- the function returns an ERR_PTR().

 + f_caps[i] = securityfs_create_file(cap_entries[i].name, 0444,
 +d_caps, cap_entries[i],
 +cap_entry_fops);
 + if (!f_caps[i])

Ditto.

Another issue is that securityfs depends on CONFIG_SECURITY, which might 
be undesirable, given that capabilities are a standard feature.


- James
-- 
James Morris
[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] Exporting capability code/name pairs

2007-12-27 Thread James Morris
On Thu, 27 Dec 2007, KaiGai Kohei wrote:


(Please put the patch above the .sig separator).

+   len = strlen(tmp);
+
+   if (ofs = len)
+   return 0;
+
+   if (len - ofs  count)
+   count = len - ofs;
+
+   rc = copy_to_user(buffer, tmp + ofs, count);
+   if (rc)
+   return rc;
+
+   *ppos += count;

Use simple_read_from_buffer().



- James
-- 
James Morris
[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] Exporting capability code/name pairs

2007-12-27 Thread James Morris
On Fri, 28 Dec 2007, KaiGai Kohei wrote:

 + snprintf(tmp, sizeof(tmp),
 +  cap_entry == cap_entries[0] ? 0x%08x :  %u,
 +  cap_entry-code);
 + len = strlen(tmp);

You don't need to call strlen(), just use scnprintf() and grab the return 
value.


- James
-- 
James Morris
[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] mm.h, security.h, key.h and preventing namespace poisoning

2007-12-25 Thread James Morris
On Tue, 25 Dec 2007, Andrew Morton wrote:

 On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris [EMAIL PROTECTED] 
 wrote:
 
+#ifdef CONFIG_SECURITY
+extern unsigned long mmap_min_addr;
+#endif
+
 #include asm/page.h
 #include asm/pgtable.h
 #include asm/processor.h
   
   Fine by me.
  
  I'll queue it for -mm  2.6.25.
 
 I don't think we need the ifdef.  If someone incorrectly refers to this
 then they'll get a link-time error rather than a compile-time error (bad). 
 But we lose an ifdef (good).

Done,  rebased the git branch.


- James
-- 
James Morris
[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] mm.h, security.h, key.h and preventing namespace poisoning

2007-12-19 Thread James Morris
On Thu, 20 Dec 2007, David Chinner wrote:

  I'm not sure I understand your namespace pollution issue, either.
 
 doing this globally:
 
 #ifdef CONFIG_SOMETHING
 extern intsome_common_name(int a, int b, int c);
 #else
 #define some_common_name(a,b,c)   0
 #endif

I suspect it may be useful ensure all global identifiers for the key 
subsystem are prefixed with key_, as 'copy_keys' does seem a little 
generic.

  +#ifdef CONFIG_SECURITY
  +extern unsigned long mmap_min_addr;
  +#endif
  +
   #include asm/page.h
   #include asm/pgtable.h
   #include asm/processor.h
 
 Fine by me.

I'll queue it for -mm  2.6.25.


- James
-- 
James Morris
[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 10/18] SELinux: Add a network node caching mechanism similar to the sel_netif_*() functions

2007-12-18 Thread James Morris
On Mon, 17 Dec 2007, Paul Moore wrote:

 On Monday 17 December 2007 3:35:28 pm Stephen Smalley wrote:
  On Fri, 2007-12-14 at 16:50 -0500, Paul Moore wrote:
   This patch adds a SELinux IP address/node SID caching mechanism similar
   to the sel_netif_*() functions.  The node SID queries in the SELinux
   hooks files are also modified to take advantage of this new
   functionality.  In addition, remove the address length information from
   the sk_buff parsing routines as it is redundant since we already have the
   address family.
 
  This is very nice - we also need the same kind of cache for port SIDs.
 
 Thanks.  Any problem if we wait until 2.6.26 for a port SID cache? 

Nope.



-- 
James Morris
[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] VM/Security: add security hook to do_brk

2007-12-05 Thread James Morris
On Tue, 4 Dec 2007, Alan Cox wrote:

 On Tue, Dec 04, 2007 at 11:06:55AM -0500, Eric Paris wrote:
  Given a specifically crafted binary do_brk() can be used to get low
  pages available in userspace virtually memory and can thus be used to
  circumvent the mmap_min_addr low memory protection.  Add security checks
  in do_brk().
  
  Signed-off-by: Eric Paris [EMAIL PROTECTED]
 
 ACK

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm

-- 
James Morris
[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: Out of tree module using LSM

2007-11-30 Thread James Morris
On Fri, 30 Nov 2007, Crispin Cowan wrote:

  The only case of this so far has been Multiadm, although there seems to be 
  no reason for it to stay out of tree.

 Dazuko. It has the same yucky code issues as Talpa, but AFAIK is pure
 GPL2 and thus is clean on the license issues.

 That these modules are valid modules that users want to use, are GPL
 clean, and are *not* something LKML wants to upstream because of code
 issues, is precisely why the LSM interface makes sense.

I think the idea is to try and fix code quality issues through 
participation in the upstream process, rather than have upstream maintain 
stable kernel APIs which are naturally mismatched to the unknown 
requirements of out of tree users.

- James
-- 
James Morris 
[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 -mm 2/2] do_wait: cleanup delay_group_leader() usage

2007-11-26 Thread James Morris
[added LSM list]

On Fri, 23 Nov 2007, Oleg Nesterov wrote:

 eligible_child() == 2 means delay_group_leader(). With the previous patch this
 only matters for EXIT_ZOMBIE task, we can move that special check to the only
 place it is really needed.
 
 Also, with this patch we don't skip security_task_wait() for the group leaders
 in a non-empty thread group. I don't really understand the exact semantics of
 security_task_wait(), but imho this change is a bugfix.

The semantics in terms of SELinux are that calls to wait() type calls need 
to be mediated by policy, as information can be transfered via the exit 
status.

It looks like a correct bugfix to me, but I'd be interested to see what 
others have to say.



 Also rearrange the code a bit to kill an ugly check_continued backdoor.
 
 Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
 
 --- PT/kernel/exit.c~6_delay_leader   2007-11-23 20:31:21.0 +0300
 +++ PT/kernel/exit.c  2007-11-23 21:29:44.0 +0300
 @@ -1137,12 +1137,6 @@ static int eligible_child(pid_t pid, int
   if (((p-exit_signal != SIGCHLD) ^ ((options  __WCLONE) != 0))
!(options  __WALL))
   return 0;
 - /*
 -  * Do not consider thread group leaders that are
 -  * in a non-empty thread group:
 -  */
 - if (delay_group_leader(p))
 - return 2;
  
   err = security_task_wait(p);
   if (err)
 @@ -1494,10 +1488,9 @@ repeat:
   tsk = current;
   do {
   struct task_struct *p;
 - int ret;
  
   list_for_each_entry(p, tsk-children, sibling) {
 - ret = eligible_child(pid, options, p);
 + int ret = eligible_child(pid, options, p);
   if (!ret)
   continue;
  
 @@ -1521,19 +1514,17 @@ repeat:
   retval = wait_task_stopped(p,
   (options  WNOWAIT), infop,
   stat_addr, ru);
 - } else if (p-exit_state == EXIT_ZOMBIE) {
 + } else if (p-exit_state == EXIT_ZOMBIE 
 + !delay_group_leader(p)) {
   /*
 -  * Eligible but we cannot release it yet:
 +  * We don't reap group leaders with subthreads.
*/
 - if (ret == 2)
 - goto check_continued;
   if (!likely(options  WEXITED))
   continue;
   retval = wait_task_zombie(p,
   (options  WNOWAIT), infop,
   stat_addr, ru);
   } else if (p-exit_state != EXIT_DEAD) {
 -check_continued:
   /*
* It's running now, so it might later
* exit, stop, or stop and then continue.
 

-- 
James Morris
[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.

2007-11-22 Thread James Morris
On Thu, 22 Nov 2007, Tetsuo Handa wrote:

 This patch allows LSM modules filter incoming connections/datagrams
 based on the process's security context who is attempting to pick up.
 
 There are already hooks to filter incoming connections/datagrams
 based on the socket's security context, but these hooks are not
 applicable when one wants to do TCP Wrapper-like filtering
 (e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).

This functionality looks like it could be useful in that we currently have 
no direct security mapping from incoming packet to user process, but only 
to the receiving socket, as you mention.  For SELinux, it may help us 
simplify/clarify policy.

It's also been long-desired for netfilter/iptables, to allow ipt_owner to 
work cleanly for incoming packets.

So, this probably needs to be implemented in a way which works for both LSM 
and netfilter.  There have been several discussions on the issue from the 
netfilter side, although I don't know what the latest status of that is 
(I've expanded the cc list to hopefully get some more feedback).

From memory, one approach under discussion was to add netfilter hooks to 
the transport layer, which could be invoked correctly by each type of 
protocol when the target process is selected.

If this is done for netfilter, then an LSM hook is probably not needed at 
all, as security modules can utilize netfilter hooks directly.

 Precautions: This approach has a side effect which unlikely occurs.
 
 If a socket is shared by multiple processes with differnt policy,
 the process who should be able to accept this connection
 will not be able to accept this connection
 because socket_post_accept() aborts this connection.
 But if socket_post_accept() doesn't abort this connection,
 the process who must not be able to accept this connection
 will repeat accept() forever, which is a worse side effect.
 
 Similarly, if a socket is shared by multiple processes with differnt policy,
 the process who should be able to pick up this datagram
 will not be able to pick up this datagram
 because socket_post_recv_datagram() discards this datagram.
 But if socket_post_recv_datagram() doesn't discard this datagram,
 the process who must not be able to pick up this datagram
 will repeat recvmsg() forever, which is a worse side effect.
 
 So, don't give different permissions between processes who share one socket.
 Otherwise, some connections/datagrams cannot be delivered to intended process.

These semantics changes are concerning, and lead me to wonder if there are 
any more.  Needs more review by networking folk.



- James
-- 
James Morris
[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: [TOMOYO #5 18/18] LSM expansion for TOMOYO Linux.

2007-11-19 Thread James Morris
On Tue, 20 Nov 2007, Tetsuo Handa wrote:

 Hello.
 
 Paul Moore wrote:
  My apologies, I mistakenly read the following if statement in your patch:
  
   +   if (skb == skb_peek(sk-sk_receive_queue)) {
   +   __skb_unlink(skb, sk-sk_receive_queue);
   +   atomic_dec(skb-users);
   +   }
  
  I read the conditional as the following:
  
   +   if (skb = skb_peek(sk-sk_receive_queue)) {
  
  ... which would have caused the problems I was describing.  I'm sorry for 
  all 
  of the confusion/frustration, you patient explanations are correct; I was 
  wrong in this particular case.
 No problem.
 
 
 
 To everyone:
 
   Are there any remaining worries with 
 skb_recv_datagram()/socket_post_accept()?
 
   If nobody has objection, I'd like to cut these 
 skb_recv_datagram()/socket_post_accept() changes
   and submit to -mm tree.

You should send anything which touches core networking to netdev, too, and 
get an ack from one of the core developers there.


-- 
James Morris [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 08/13] SELinux: Add new peer permissions to the Flask definitions

2007-11-11 Thread James Morris
On Fri, 9 Nov 2007, Paul Moore wrote:

 Add additional Flask definitions to support the new peer object class.

Should this be dependent on dynamic class/permission support?

Or, will these checks only be invoked if labled networking is configured?


-- 
James Morris
[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 09/13] SELinux: Better integration between peer labeling subsystems

2007-11-11 Thread James Morris
On Fri, 9 Nov 2007, Paul Moore wrote:

 + /* Between selinux_compat_net and selinux_policycap_netpeer this is
 +  * starting to get a bit messy - we need to setup a timetable for
 +  * deprecating some of this old/obsolete functionality so we can
 +  * reclaim some level of sanity in this function. */

I don't think we can do anything which could potentially break userspace 
now.

So, this one really needs to be right :-)


-- 
James Morris
[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 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

2007-11-01 Thread James Morris
On Thu, 1 Nov 2007, David P. Quigley wrote:

 This patch modifies the interface to inode_getsecurity to have the function
 return a buffer containing the security blob and its length via parameters
 instead of relying on the calling function to give it an appropriately sized
 buffer. Security blobs obtained with this function should be freed using the
 release_secctx LSM hook. This alleviates the problem of the caller having to
 guess a length and preallocate a buffer for this function allowing it to be
 used elsewhere for Labeled NFS. The patch also removed the unused err
 parameter. The conversion is similar to the one performed by Al Viro for the
 security_getprocattr hook.
 
 Signed-off-by: David P. Quigley [EMAIL PROTECTED]

Acked-by: James Morris [EMAIL PROTECTED]

-- 
James Morris
[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: [AppArmor 34/45] Factor out sysctl pathname code

2007-10-26 Thread James Morris
On Thu, 25 Oct 2007, [EMAIL PROTECTED] wrote:

 Convert the selinux sysctl pathname computation code into a standalone
 function.
 
 Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
 Signed-off-by: John Johansen [EMAIL PROTECTED]

Reviewed-by: James Morris [EMAIL PROTECTED]



-- 
James Morris
[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 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

2007-10-23 Thread James Morris
On Mon, 22 Oct 2007, David P. Quigley wrote:

 +static inline int security_inode_getsecurity(const struct inode *inode,
 + const char *name,
 + void **buffer)

It's better to keep function declarations on one line if possible (the 
80-col rule can be broken for this).

But in any case, it looks ok to me.


Acked-by: James Morris [EMAIL PROTECTED]


-- 
James Morris
[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: [TOMOYO 05/15](repost) Domain transition handler functions.

2007-10-03 Thread James Morris
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:

 In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo 
 Handa [EMAIL PROTECTED] says:
 
  It seems that standard kernel list API does not have singly-linked list 
  manipulation.
  I'm considering the following list manipulation API.
 
 Tstsuo, please name it slist, which is well-known.

I'm pretty sure that the singly linked list idea has been rejected a few 
times.  Just use the existing API.

-- 
James Morris
[EMAIL PROTECTED]

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

2007-10-03 Thread James Morris
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:

 In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo 
 Handa [EMAIL PROTECTED] says:
 
  Peter Zijlstra wrote:
   Also, how do you avoid referencing dead data with your sll? I haven't
   actually looked at your patches, but the simple scheme you outlined
   didn't handle the iteration + concurrent removal scenario:
  Regarding my singly-linked list, no entries are removed from the list. It's 
  append only (like CD-R media).
  I set is_deleted flag of a entry instead of removing the entry from the 
  list.
 
 It is not a good practice.  Please free such objects.
 BTW, how many objects do you have in the list?

Doesn't matter.  No list should be able to grow without bounds in the 
kernel.

-- 
James Morris
[EMAIL PROTECTED]

Re: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP

2007-10-03 Thread James Morris
On Wed, 3 Oct 2007, Serge E. Hallyn wrote:

 From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001
 From: Serge E. Hallyn [EMAIL PROTECTED]
 Date: Fri, 28 Sep 2007 10:33:33 -0500
 Subject: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP
 
 currently the compilation of commoncap.c is determined
 through Makefile logic.  So there is no single CONFIG
 variable which can be relied upon to know whether it
 will be compiled.
 
 Define CONFIG_COMMONCAP to be true when lsm is not
 compiled in, or when the capability or rootplug modules
 are compiled.  These are the cases when commoncap is
 currently compiled.  Use this variable in security/Makefile
 to determine commoncap.c's compilation.
 
 Apart from being a logic cleanup, this is needed by the
 upcoming cap_bset patch so that prctl can know whether
 PR_SET_BSET should be allowed.
 
 Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]

Acked-by: James Morris [EMAIL PROTECTED]


-- 
James Morris
[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: [TOMOYO 00/15](repost) TOMOYO Linux - MAC based on process invocation history.

2007-10-02 Thread James Morris
It seems that patches 1-3 are missing.

I'd also suggest making all of the patches a reply to the first email, so 
they can be threaded.



- James
-- 
James Morris
[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: [TOMOYO 05/15](repost) Domain transition handler functions.

2007-10-02 Thread James Morris
On Tue, 2 Oct 2007, Kentaro Takeda wrote:

 +
 + mb(); /* Instead of using spinlock. */
 + ptr = domain_initializer_list;
 + if (ptr) {
 + while (ptr-next)
 + ptr = ptr-next;
 + ptr-next = new_entry;
 + } else
 + domain_initializer_list = new_entry;
 +

Please use standard kernel list handling, per include/linux/list.h

Why do you need to avoid spinlocks for these manipulations?



- James
-- 
James Morris
[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: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.

2007-10-02 Thread James Morris
On Tue, 2 Oct 2007, Kentaro Takeda wrote:

 LSM expansion for TOMOYO Linux.
 
 LSM hooks for sending signal:
* task_kill_unlocked is added in sys_kill
* task_tkill_unlocked is added in sys_tkill
* task_tgkill_unlocked is added in sys_tgkill

Why do you need racy unlocked versions, in addition to the existing 
security_task_kill() hook which is called safely via 
check_kill_permission() ?


- James
-- 
James Morris
[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: [TOMOYO 05/15](repost) Domain transition handler functions.

2007-10-02 Thread James Morris
On Tue, 2 Oct 2007, Tetsuo Handa wrote:

 Hello.
 
 Thank you for your comment.
 
 James Morris wrote:
  Why do you need to avoid spinlocks for these manipulations?
 
 I don't need to use spinlocks here.
 What I need to do here is avoid read/write reordering,
 so mb() will be appropriate here.
 
 struct something {
   struct something *next;
   void *data;
 };
 
 struct something *prev_ptr = ...;
 struct something *new_ptr = kmalloc(sizeof(*new_ptr), GFP_KERNEL);
 new_ptr-next = NULL;
 new_ptr-data = some_value;
 mb();
 prev_ptr-next = new_ptr;

You're introducing a custom API, which is open-coded repeatedly throughout 
your module.

All linked lists (at least, new ones) must use the standard kernel list
API.

 Performance is not critical because this mb() is called
 only when appending new entry to the singly-linked list.

Most of these uses appear to be slow path or nested inside other locks, 
while overall, performance is likely to be dominated by your string 
matching and permission checking.  Use of mb(), which is typically 
considered less understandable, in this case does not appear to be 
justified vs. normal locking, and you also need to use the standard list 
API.  If performance really is an issue, then consider RCU.


- James
-- 
James Morris
[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

2007-10-01 Thread James Morris
On Sun, 30 Sep 2007, Andrew Morton wrote:

 So with the information which I presently have available to me, I'm
 thinking that this should go into 2.6.24.

I think the decision to merge Smack is something that needs to be 
considered in the wider context of overall security architecture.

Smack itself looks fine.  It seems like clean code with interesting ideas, 
and appears to be based upon sound principles.

Merging Smack, however, would lock the kernel into the LSM API.  
Presently, as SELinux is the only in-tree user, LSM can still be removed.

LSM's weak semantics and pervasive deep hooking of the kernel means that 
we'll have to continue dealing with several unpleasant issues, such as the 
abuse of the API by out of tree vendors, with a proliferation of 
binary/proprietary modules which typically maladapt the API for arbitrary 
purposes and/or use dangerous techniques.  We will continue to waste 
resources maintaining this capability for them.

On a broader scale, we'll miss the potential of Linux having a coherent, 
semantically strong security architecture. I have written about this in 
some detail before: http://lwn.net/Articles/240019/

Briefly, SELinux is a security architecture.  It provides an extremely 
high degree of flexibility, in terms of both the types of security models 
implemented, and security policy for those models.  It allows controlled 
composition of different security models, with a common policy language 
framework, allowing the entire system to be analyzed.  The same ideas and 
even code can be reused beyond the kernel as post-DAC security is extended 
into databases, the desktop, distributed applications etc.  It is a 
framework which provides a structured, coherent view of the security of 
the OS (and ultimately, the entire distributed environment).

If LSM remains, security will never be a first class citizen of the 
kernel.  Application developers will see multiple security schemes, and 
either burn themselves trying to support them, or more likely, ignore 
them.
 
Core kernel developers will continue to not have enough information to 
understand what the LSM hooks in their code are supposed to be doing, 
leading to long term maintenance issues and potential security problems.

LSM will remain a magnet for bad ideas.  There's a reason we don't have 
pluggable network stacks, and we are lucky to have had a unified 
networking framework maintained by people who know to say no to things 
like STREAMS and TOE.  I would question whether this quality of 
maintainership would exist if the networking core was simply a bunch of 
deep hooks into which people dumped arbitrary custom stacks.

LSM will prevent us from making systemic improvements to security, as 
there will be no common security architecture.  Things like Netfilter 
would not have been viable with a kernel which simply provided a bunch of 
hooks for networking stacks and an assortment of implementations.

Much of this we have learned from the experience of LSM, and I think it 
has been valuable for that, but I think we need to consider now whether we 
are going to continue down this track in a permanent manner.


- James
-- 
James Morris
[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 1/1] file capabilities: clear fcaps on inode change (v2)

2007-08-07 Thread James Morris
On Mon, 6 Aug 2007, Serge E. Hallyn wrote:

 + err = security_inode_killpriv(out-f_path.dentry, LSM_NEED_LOCK);
 + if (err)
 + return err;
 +
   err = should_remove_suid(out-f_path.dentry);
   if (unlikely(err)) {
   mutex_lock(inode-i_mutex);

It seems hackish to pass a needlock arg to an API, and that that we'll end 
up with some conceptually similar call-outs for both caps and setuid.

How about encapsulating this stuff so that there's something like:


err = should_remove_privs();
if (err)
remove_privs();

with

void remove_privs()
{
mutex_lock();
__remove_privs();
mutex_unlock();
}

and then __remove_privs() handles the logic for all file privileges, 
including at this stage suid and the LSM call for file caps ?



- James
-- 
James Morris
[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 1/1] file capabilities: don't ensure we break with 64-bit caps

2007-08-07 Thread James Morris
On Mon, 6 Aug 2007, Serge E. Hallyn wrote:

 +struct vfs_cap_data_v2 {
 + __u32 magic_etc;  /* Little endian */
 + struct {
 + __u32 permitted_lo;/* Little endian */
 + __u32 permitted_hi;/* Little endian */
 + __u32 inheritable_lo;  /* Little endian */
 + __u32 inheritable_hi;  /* Little endian */
 + } data[1];
 +};

why not __le32 ?

I think this needs to be settable at runtime via a sysctl, and also 
possibly overridable via LSM.

-- 
James Morris
[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 1/1] file capabilities: clear fcaps on inode change (v2)

2007-08-07 Thread James Morris
On Tue, 7 Aug 2007, Serge E. Hallyn wrote:

 Shall I resend without the LSM_NEED_LOCK, or do you still want a more
 fundamental change?


Removing the needlock is enough, the rest was just a query/suggestion.


-- 
James Morris
[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: file capabilities: clear fcaps on inode change (v3)

2007-08-07 Thread James Morris
On Tue, 7 Aug 2007, Serge E. Hallyn wrote:

 Yeah, I did that in v1, but didn't want to add two new security_ hooks.
 But I'll send a v4 doing that.

Yep, add what's actually needed.

Continually having to jump through all of these hoops for LSM has gone 
beyond ridiculous.



- James 
-- 
James Morris
[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] Version6 - Simplified mandatory access control kernel implementation

2007-07-25 Thread James Morris
Also,

+   mutex_lock(smack_cipso_lock);
+
+   for (scp = smack_cipso; scp != NULL; scp = scp-smk_next)
+   if (mapsmack == scp-smk_smack)
+   break;
+
+   if (scp == NULL) {
+   scp = kzalloc(sizeof(struct smk_cipso_entry),
+   GFP_KERNEL);
+   if (scp == NULL) {
+   rc = -ENOMEM;
+   break;
+   }
+   scp-smk_next = smack_cipso;
+   scp-smk_smack = mapsmack;
+   scp-smk_level = maplevel;
+   scp-smk_catset = mapcatset;
+   wmb();
+   smack_cipso = scp;
+   /*
+* Add this to ensure that there are enough bytes
+* for the regurgitation
+*/
+   smk_cipso_written += sizeof(smack_t);
+   }
+
+   mutex_unlock(smack_cipso_lock);

Why do you have a wmb() here ?  The mutex lock acts as a full memory 
barrier.

-- 
James Morris
[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] Version6 - Simplified mandatory access control kernel implementation

2007-07-25 Thread James Morris
On Wed, 25 Jul 2007, Casey Schaufler wrote:

 Out come the wmb() calls. I'm still working on learning the details
 of the locking models and I wasn't looking at a large enough scope
 in the example to which I'd been pointed.

IIRC, one call was not protected by the mutex barrier, but I wasn't sure 
if it was still needed or not.


-- 
James Morris
[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] Version4 - Simplified mandatory access control kernel implementation

2007-07-23 Thread James Morris
On Mon, 23 Jul 2007, Seth Arnold wrote:

 Are GFP_KERNEL allocations kosher inside a spinlock?

No, and building and testing with all of the lock debugging enabled should 
show up many issues such as this.



-- 
James Morris
[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] Simplified mandatory access control kernel implementation

2007-07-20 Thread James Morris
On Thu, 19 Jul 2007, Greg KH wrote:

 Why not do it here on this list?  It is security related and I'm sure
 that other security model implementations will be interested in it.

Labeled NFS is aimed at being cross platform, and we hope to have 
non-Linux folk particpiating actively.  The LSM list may not be the best 
place for it.


 It's not like we need yet-another-list :)

I'm only subscribed to about 130 lists (on this account).



- James
-- 
James Morris
[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 1/1] Allow LSM to use IP address/port number.

2007-07-20 Thread James Morris
On Sat, 21 Jul 2007, Tetsuo Handa wrote:

 I can't use netfilter infrastructure because
 it is too early to know who the recipant process of the packet is.

I think the way forward on this is to re-visit the idea of providing a 
proper solution for the incoming packet/user match problem.

I posted one possible solution a couple of years ago (skfilter):
http://lwn.net/Articles/157137/

I think there has been some recent discussion by netfilter developers 
about this issue, so perhaps you could talk to them (cd'd Patrick).


- James
-- 
James Morris
[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 try #3] security: Convert LSM into a static interface

2007-07-19 Thread James Morris
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:

 If we could get a few (non-afilliated :) people who work with
 customers in the security field to tell us whether this is being
 used, that would be very helpful.  Not sure how to get that.

The mainline kernel does not cater to out of tree code.

 Or we just apply the patch and see who yells  :)


It's already pretty clear.



- James
-- 
James Morris
[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 try #3] security: Convert LSM into a static interface

2007-07-19 Thread James Morris
On Thu, 19 Jul 2007, Serge E. Hallyn wrote:

  It's already pretty clear.
 
 I doubt anyone not on lkml or linux-security-module has heard of this.
 
 So we'll see.
 
 (I was, obviously, talking about end-users)

If distributions are shipping binary modules and other out of tree code to 
their users, then they should bear responsibility for supporting and 
maintaining the infrastructure required for it, and not expect upstream 
maintainers to do it for them.

Additionally, if they want to expose their users to risks arising from 
broken and unecessary infrastructure, then they should bear the cost and 
responsibility of doing that and not expect others to do so as well.

I don't see how this is even slightly difficult to understand.



- James
-- 
James Morris
[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 try #3] security: Convert LSM into a static interface

2007-07-19 Thread James Morris
On Thu, 19 Jul 2007, Jim Kovaric wrote:

 IBMs  TAMOS (Tivoli Access Manager for Operating systems) contains a 
 loadable module,
  which is an out of tree module,  and registers itself  as a security 
 module during the TAMOS startup
 process. It also requires that SElinux  be disabled

Please provide a link to the source code, so we can understand how you're 
using the API.



- James
-- 
James Morris
[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 try #3] security: Convert LSM into a static interface

2007-07-19 Thread James Morris
On Thu, 19 Jul 2007, James Morris wrote:

 On Thu, 19 Jul 2007, Jim Kovaric wrote:
 
  IBMs  TAMOS (Tivoli Access Manager for Operating systems) contains a 
  loadable module,
   which is an out of tree module,  and registers itself  as a security 
  module during the TAMOS startup
  process. It also requires that SElinux  be disabled
 
 Please provide a link to the source code, so we can understand how you're 
 using the API.

I think I've found it:

ftp://ftp.software.ibm.com/software/tivoli_support/patches/patches_6.0.0/6.0.0-TIV-PDO-FP0007/6.0.0-TIV-PDO-Linux.i386-FP0007.tar

Is that correct?

  kail_trap_syscalls() 

seems to be revectoring the syscall table and siliently disabling any 
active LSM.


  kail_restore_syscalls()

attempts to restore them on module unload.


Is my understanding correct?

You're shipping this to customers as a security feature?


- James
-- 
James Morris
[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] Simplified mandatory access control kernel implementation

2007-07-19 Thread James Morris
On Thu, 19 Jul 2007, Joshua Brindle wrote:

  I also see an effort that's SELinux specific. Should be fun.

 
 The SELinux part is going to be a profile on top of the generic part so there
 shouldn't be any conflicts in the implementation.

I wonder if it'd be worth setting up a mailing list specifically for this.  
We currently have too much off-list discussion happening, and nowhere 
really good to have it on-list.

Thoughts?


- James
-- 
James Morris
[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 try #3] security: Convert LSM into a static interface

2007-07-18 Thread James Morris
On Wed, 18 Jul 2007, Andrew Morton wrote:

  The SECURITY_FRAMEWORK_VERSION macro has also been removed.
 
 I'd like to understand who is (or claims to be) adversely affected by this
 change, and what their complaints (if any) will be.
 
 Because I prefer my flamewars pre- rather than post-merge.

This was already discussed and resolved during previous postings of the 
patch.

In a nutshell, there is no safe way to unload an LSM.  The modular 
interface is thus unecessary and broken infrastructure.  It is used only 
by out-of-tree modules, which are often binary-only, illegal, abusive of 
the API and dangerous, e.g. silently re-vectoring SELinux.

Chris has already agreed to take the patch:  
http://lkml.org/lkml/2007/6/24/152


 aww man, you passed over an opportunity to fix vast amounts of coding style
 cruftiness.

GregKH-esque :-)

 does whizzy things
 
 Here you go..

Thanks.


-- 
James Morris
[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 1/2] file capabilities: change xattr format (v2)

2007-07-14 Thread James Morris
On Fri, 13 Jul 2007, Serge E. Hallyn wrote:

 Finally, future format compatibility is reduced.  If
 a security.capability xattr is found with too new a version,
 don't run the binary.

I wonder if the behavior of this should be configurable, so that the admin 
can decide what to do here.  She may wish to simply ignore file caps with 
a newer version (e.g. behave like the -ENODATA case).



- James
-- 
James Morris
[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] file capabilities: change fE to a bool

2007-07-14 Thread James Morris
On Fri, 13 Jul 2007, Serge E. Hallyn wrote:

 From 3549aced829f84237ddc3ccfa571b8a938cae173 Mon Sep 17 00:00:00 2001
 From: Serge E. Hallyn [EMAIL PROTECTED]
 Date: Fri, 13 Jul 2007 12:17:45 -0400
 Subject: [PATCH 2/2] file capabilities: change fE to a bool
 
 The fE was previously a full capset which was masked with the
 calculated new_permitted to get the process' new effective set.
 It is now a single bit in the xattr.  This patch changes
 bprm-cap_effective to a boolean.  When that boolean is false,
 then P'e is the empty set.  When the boolean is true, then P'e is
 set equal to P'p (new_permitted).  The rationale for this is that
 either the application does not know about capabilities, and
 needs to start with all permitted caps in its effective set, or
 it does know about capabilities, and can start with an empty
 effective set and enable the caps it wants when it wants.
 
 Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]

Acked-by: James Morris [EMAIL PROTECTED]



-- 
James Morris
[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 1/1] file capabilities: clear caps cleanup

2007-07-11 Thread James Morris
On Wed, 11 Jul 2007, Serge E. Hallyn wrote:

 From 88115394044e697ac852f7fb9f30483e87f4f598 Mon Sep 17 00:00:00 2001
 From: Serge E. Hallyn [EMAIL PROTECTED]
 Date: Wed, 11 Jul 2007 10:01:01 -0400
 Subject: [PATCH 1/1] file capabilities: clear caps cleanup
 
 As suggested by Steve Beattie, rather than jump into a
 conditional block in certain cases, define and use a
 static inline bprm_clear_caps().
 
 Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]

Good idea.

Acked-by: James Morris [EMAIL PROTECTED]


-- 
James Morris
[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] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.)

2007-07-09 Thread James Morris
On Mon, 9 Jul 2007, Tetsuo Handa wrote:

 Hello.
 
 This thread is from http://marc.info/?t=11834645705r=1w=2 .
 
 I want to use tcp_wrapper-like filtering using LSM.

The appropriate way to do this would be via netfilter queuing to 
userspace, as already suggested by Paul Moore.


-- 
James Morris
[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] Allow LSM to use IP address/port number.

2007-07-09 Thread James Morris
On Mon, 9 Jul 2007, Stephen Hemminger wrote:

 Isn't it better to hook into existing netfilter infrastructure somehow?

Yes, it has been suggested several times.


-- 
James Morris
[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 try #2] security: Convert LSM into a static interface

2007-06-27 Thread James Morris
On Wed, 27 Jun 2007, Serge E. Hallyn wrote:

 Patch tests fine for me for expected capability behavior with lsm=n,
 lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y.
 
 So while I'm opposed to the patch, it appears to be safe.

I've also tested a bunch of scenarios: allmodconfig, lsm=y,cap=n, 
selinux=y,cap=n  etc.


-- 
James Morris
[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] security: Convert LSM into a static interface

2007-06-25 Thread James Morris
On Mon, 25 Jun 2007, Casey Schaufler wrote:

 While there's lots of pain involved in developing an LSM
 modern development environments (e.g. virtual machines)
 have reduced the value of loadable modules for debug purposes.

lguest is pretty good for this.  You can boot a kernel in approximately 
the same time as loading a module.

-- 
James Morris
[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 try #2] security: Convert LSM into a static interface

2007-06-25 Thread James Morris
On Mon, 25 Jun 2007, Andreas Gruenbacher wrote:

 It's useful for some LSMs to be modular, and LSMs which are y/n options won't 
 have any security architecture issues with unloading at all. 

Which LSMs?  Upstream, there are SELinux and capabilty, and they're not 
safe as loadable modules.

 The mere fact 
 that SELinux cannot be built as a module is a rather weak argument for 
 disabling LSM modules as a whole, so  please don't.

That's not the argument.  Please review the thread.


- James
-- 
James Morris
[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: What kind of feature does New LSM security model need?

2007-06-25 Thread James Morris
On Tue, 26 Jun 2007, Kazuki Omo(Company) wrote:

 Folks,
 
 May I ask some foolish questions?
 I just want to make sure what do we need
 if we want to put new security module(which is using LSM) in mainline.

(Note, the following are just my opinions).

 
 1. Does it have to provide complete MAC which  Casey Schaufler
explained in below mail?
http://marc.info/?l=linux-kernelm=118252843017261w=2

No.

 2. Does it have to provide any solution which SELinux can't cover?
 
 3. Do we have to proof the new security module can't implement
as policy on SELinux?

The questions I would ask, given that SELinux has been upstream for 
several years, and that SELinux is itself an extensible security framework 
designed to allow composition of different security models in a consistent 
manner:

- why would you duplicate existing functionality ?

- did you try and solve the problem with SELinux (either using the 
existing models or by adding new ones) ?

More generally, I would question whether Linux is really best served by a 
disparate set of security schemes with no underlying design.

 4. Does it have to provide complete security feature from beginning?
Can we implement just small features to mainline and develop
new features in same time?

This varies between subsystems, but it would probably need to meet a 
useful set of goals.

 5. Does it have to have any Security model which documented/evaluated
in academic conference?

No, but you should be able to explain the requirements, the model and the 
implementation.


-- 
James Morris
[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: implement-file-posix-capabilities.patch

2007-06-24 Thread James Morris
On Sun, 24 Jun 2007, Serge E. Hallyn wrote:

  2) Allocate capability bit-31 for CAP_SETFCAP, and use it to gate
  whether the user can set this xattr on a file or not. CAP_SYS_ADMIN is
  way too overloaded and this functionality is special.
 
 The functionality is special, but someone with CAP_SYS_ADMIN can always
 unload the capability module and create the security.capability xattr
 using the dummy module.
 
 If we do add this cap, do we want to make it apply to all security.*
 xattrs?

The underlying issue here is the notion of security mechanisms which are 
built as loadable modules.  It's not useful for any in-tree users, and 
introduces several unnecessary problems which then need to be addressed.

A better approach would be to make LSM a statically linked interface.

This would also allow us to unexport the LSM symbols and reduce the API 
abuse by third-party modules.


- James
-- 
James Morris
[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 try #2] security: Convert LSM into a static interface

2007-06-24 Thread James Morris
On Sun, 24 Jun 2007, Petr Vandrovec wrote:

  -module_param(debug, bool, 0600);
  -MODULE_PARM_DESC(debug, Debug enabled or not);
  +static int __init root_plug_debug(char *str)
  +{
  +   debug = simple_strtol(str, NULL, 0);
  +   return 1;
  +}
  +__setup(root_plug_debug=, root_plug_debug);
 
 is this necessary?  What about just documenting
 root_plug.{vendor_id,product_id,debug}, so it won't break existing root_plug
 users (if there are any) ?  I thought that typed module_param() is prefered
 over untyped __setup()...

I didn't know module_param was preferred.

The idea was that root_plug is example code, and should do the typical 
thing, which I thought would be __setup.

I can easily change it if needed.


-- 
James Morris
[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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-21 Thread James Morris
On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote:

 A veto is not a technical argument. All technical arguments (except for
 path name is ugly, yuk yuk!) have been addressed, have they not?

AppArmor doesn't actually provide confinement, because it only operates on 
filesystem objects.

What you define in AppArmor policy does _not_ reflect the actual 
confinement properties of the policy.  Applications can simply use other 
mechanisms to access objects, and the policy is effectively meaningless.

You might define this as a non-technical issue, but the fact that AppArmor 
simply does not and can not work is a fairly significant consideration, I 
would imagine.



- James
-- 
James Morris
[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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-15 Thread James Morris
On Fri, 15 Jun 2007, Greg KH wrote:

 Oh great, then things like source code control systems would have no
 problems with new files being created under them, or renaming whole
 trees.

It depends -- I think we may be talking about different things.

If you're using inotify to watch for new files and kick something in 
userspace to relabel them, it could take a while to relabel a lot of 
files, although there are likely some gains to be had from parallel 
relabeling which we've not explored.

What I was saying is that you can use traditional SELinux labeling policy 
underneath that to ensure that there is always a safe label on each file 
before it is relabeled from userspace.

 So, so much for the it's going to be too slow re-labeling everything
 issue, as it's not even required for almost all situations :)

You could probably get an idea of the cost by running something like:

$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar

On my system, it takes about 1.2 seconds to label a fully checked out 
kernel source tree with ~23,000 files in this manner, on a stock standard 
ext3 filesystem with a SATA drive.



- James
-- 
James Morris
[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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-15 Thread James Morris
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:

 on the contrary, useing 'mv' is by far the cleanest way to do this.
 
 mv htdocs htdocs.old;mv htdocs.new htdocs
 
 this makes two atomic changes to the filesystem, but can generate thousands to
 millions of permission changes as a result.

OTOH, you've performed your labeling up front, and don't have to 
effectively relabel each file each time on each access, which is what 
you're really doing with pathname labeling.



- James
-- 
James Morris
[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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-15 Thread James Morris
On Fri, 15 Jun 2007, Seth Arnold wrote:

  How does inotify not work here?  You are notified that the tree is
  moved, your daemon goes through and relabels things as needed.  In the
  meantime, before the re-label happens, you might have the wrong label on
  things, but somehow SELinux already handles this, so I think you
  should be fine.
 
 SELinux does not relabel files when containing directories move, so it
 is not a problem they've chosen to face.

It's a deliberate design choice, and follows traditional Unix security 
logic.  DAC permissions don't change on every file in the subtree when you 
mv directories, either.




- James
-- 
James Morris
[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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSMhook

2007-05-29 Thread James Morris
On Tue, 29 May 2007, Casey Schaufler wrote:

  Conventional UNIX's access control can't restrict
  which path_to_file can link with which another_path_to_file
  because UNIX's access control is a label-based access control.
 
 UNIX access control is attribute based, not label based. The
 distinction may be hair splitting in the current context, but
 could be significant later if the thread continues. 

What's important is that traditional DAC stores the security attributes 
of the object with the object.  Call them what you want, it matters not.


- James
-- 
James Morris
[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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-26 Thread James Morris
On Fri, 25 May 2007, Crispin Cowan wrote:

 Finally, AA doesn't care what the contents of the executable are. We
 assume that it is a copy of metasploit or something, and confine it to
 access only the resources that the policy says.

As long as these resources are only files.  There is no confinement beyond 
that.


- James
-- 
James Morris
[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: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-24 Thread James Morris
On Thu, 24 May 2007, Andreas Gruenbacher wrote:

  Would you mind providing some concrete examples of how such a model would
  be useful?
 
 The model is explained, with examples, in the technical documentation at 
 http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.

I'm asking specifically about a model where you'd want to provide 
differing access to the same objects based on the pathname used for 
access to the objects, per:

  If files are mounted at multiple locations, then the policy may allow 
   access to some locations but not to others.  That's not a hole.

I don't see specific examples of this kind of policy in that document, 
and the document seems to be saying quite the opposite -- that the AA 
policy is only valid in conjunction with further constraints on how the 
objects may be accessed:

Section 3.2:

 Pathnames are meaningful only within a namespace. Each namespace has a 
  root where all the files, directories, and mount points are hanging off 
  from.

  The privilege of creating new namespaces is bound to the CAP_ SYS_ ADMIN 
  capability, which grants a multitude of other things that would allow a 
  process to break out of AppArmor confinement, so confined processes are 
  not supposed to have this privilege, and processes with this capability 
  need to be considered trusted. 


I can restate my question and ask why you'd want a security policy like:

  Subject 'sysadmin' has:
 read access to /etc/shadow
 read/write access to /views/sysadmin/etc/shadow

where the objects referenced by the paths are identical and visible to the 
subject along both paths, in keeping with your description of policy may 
allow access to some locations but not to others ?


- James
-- 
James Morris
[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: AppArmor FAQ

2007-04-18 Thread James Morris
On Tue, 17 Apr 2007, Alan Cox wrote:

 I'm not sure if AppArmor can be made good security for the general case,
 but it is a model that works in the limited http environment
 (eg .htaccess) and is something people can play with and hack on and may
 be possible to configure to be very secure.

Perhaps -- until your httpd is compromised via a buffer overflow or 
simply misbehaves due to a software or configuration flaw, then the 
assumptions being made about its use of pathnames and their security 
properties are out the window.

Without security labeling of the objects being accessed, you can't protect 
against software flaws, which has been a pretty fundamental and widely 
understood requirement in general computing for at least a decade.


- James
-- 
James Morris
[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


  1   2   >