[GIT PULL] keys bugfix
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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()
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
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
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
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]
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
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
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.
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
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.
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.
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
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
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
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
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
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
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
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
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
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
[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.
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.
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
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
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
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
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
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.
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.
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
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.
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.
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.
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.
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
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)
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
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)
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)
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
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
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
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
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.
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
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
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
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
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
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
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)
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
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
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.)
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.
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
