Re: [GIT] Security subsystem updates for 3.13
Sorry about all this -- we'll do better next time. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
Sorry about all this -- we'll do better next time. -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Fri, Nov 22, 2013 at 12:25 PM, David Howells wrote: > Linus Torvalds wrote: > >> So for future cases: if there are big independent overhauls of core >> subsystems, I'd really like to see them kept separate, ok? > > Since the trusted and encrypted keys that Mimi and Dmitry deal with are also > more akin to the keyring stuff, should they go through the keyring branch? > And does James want to hold that branch? So by now, the changes are hopefully smaller and general "updates" rather than big new features. At that point, I don't care too deeply. It's the "this is a whole new big way of doing things, and there's fundamental new core code" that I would really like to be able to see separately in order to make it much easier for me to pull and walk through independently of the normal "updates to subsystem" stuff. > I wrote it in userspace where I could easily drive it with huge numbers of > entries (add a million keys, say, delete them randomly and check at each step > that each remaining key can still be found) and also valground it. For > reference, what's the best way of showing you something like this? Quite frankly, I just want to *know* about things like this, there doesn't have to be some fixed format for it. It can be part of the pull request, explaining where the code comes from, how it's been tested, who has looked at it etc etc. Or it can be just free-form in the commit messages. And again, this - for me - is about core code that isn't deeply embedded in some internal subsystem. So the reason I reacted to the assoc_array.c thing is that it was clearly set up to be generic, and it does end up being pretty different and affects "normal" users. So I go off looking for "ok, where can I find this discussed" for doing some minimal due diligence on a new set of core code, and I find very little on lkml, and nothing else. And the commit message talks about what it does, but not about the "who looked at it", so I basically had nothing to judge it by except just looking at the code. Which didn't look horrible, but it really would have made me happier hearing about people looking it over, and about you testing it in user space etc etc. > I did show it to Paul McKenney - and he gave me some comments on it, though I > didn't ask for a Reviewed-by line, which in retrospect I should've done. > > Should we have a "Comments-from: x " line for this? So that people who > made comments but don't want to say they've properly reviewed it can be > recognised formally? A "reviewed-by" line is fine, but so is really just free-form explanations too. Not everything has to be a "xyz-by:" thing, especially things that are more important for one-time use at merge time rather than anything "this is a common pattern and people might want to do statistics about it over time". It's too late for this case, and for all I know there are no similar cases coming up in the security layer, but when I have something that ends up being pending for a two weeks, I want to at least try to educate people about *why* it was pending, and what I found difficult about the process. Maybe it happens again, maybe it won't. But if it does, we'll have at least spoken about the issues. > Is there some way in the GIT repo to associate an 'extended explanation' with > several patches? In theory, you can use notes, but I don't actually like it either technically _or_ from a "flow of information" standpoint, so I'd much rather see people try to note things in the commit messages, and then for the merge itself try to have explanations in the "please pull" message. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Fri, Nov 22, 2013 at 12:25 PM, David Howells dhowe...@redhat.com wrote: Linus Torvalds torva...@linux-foundation.org wrote: So for future cases: if there are big independent overhauls of core subsystems, I'd really like to see them kept separate, ok? Since the trusted and encrypted keys that Mimi and Dmitry deal with are also more akin to the keyring stuff, should they go through the keyring branch? And does James want to hold that branch? So by now, the changes are hopefully smaller and general updates rather than big new features. At that point, I don't care too deeply. It's the this is a whole new big way of doing things, and there's fundamental new core code that I would really like to be able to see separately in order to make it much easier for me to pull and walk through independently of the normal updates to subsystem stuff. I wrote it in userspace where I could easily drive it with huge numbers of entries (add a million keys, say, delete them randomly and check at each step that each remaining key can still be found) and also valground it. For reference, what's the best way of showing you something like this? Quite frankly, I just want to *know* about things like this, there doesn't have to be some fixed format for it. It can be part of the pull request, explaining where the code comes from, how it's been tested, who has looked at it etc etc. Or it can be just free-form in the commit messages. And again, this - for me - is about core code that isn't deeply embedded in some internal subsystem. So the reason I reacted to the assoc_array.c thing is that it was clearly set up to be generic, and it does end up being pretty different and affects normal users. So I go off looking for ok, where can I find this discussed for doing some minimal due diligence on a new set of core code, and I find very little on lkml, and nothing else. And the commit message talks about what it does, but not about the who looked at it, so I basically had nothing to judge it by except just looking at the code. Which didn't look horrible, but it really would have made me happier hearing about people looking it over, and about you testing it in user space etc etc. I did show it to Paul McKenney - and he gave me some comments on it, though I didn't ask for a Reviewed-by line, which in retrospect I should've done. Should we have a Comments-from: x y@z line for this? So that people who made comments but don't want to say they've properly reviewed it can be recognised formally? A reviewed-by line is fine, but so is really just free-form explanations too. Not everything has to be a xyz-by: thing, especially things that are more important for one-time use at merge time rather than anything this is a common pattern and people might want to do statistics about it over time. It's too late for this case, and for all I know there are no similar cases coming up in the security layer, but when I have something that ends up being pending for a two weeks, I want to at least try to educate people about *why* it was pending, and what I found difficult about the process. Maybe it happens again, maybe it won't. But if it does, we'll have at least spoken about the issues. Is there some way in the GIT repo to associate an 'extended explanation' with several patches? In theory, you can use notes, but I don't actually like it either technically _or_ from a flow of information standpoint, so I'd much rather see people try to note things in the commit messages, and then for the merge itself try to have explanations in the please pull message. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, 21 Nov 2013, Linus Torvalds wrote: > I do see *some* minimal comments on it from George Spelvin on lkml. I'd like to apologize for dropping the ball on that. I started working on it seriously, but with various emergencies, I've been AFK from lkml for the last month. I'm not really thilled with it; I think the fanout of 16 is low for something with its scale ambitions, and the properties expected of the chunked key access method are not documented as clearly as they should be. The way the key is fiddled the put keyring objects in a contiguous range of the trie is a particularly egregious layering violation. But I am convinced that it's been tested and works; my complaints are in the areas of ugliness and efficiency. And it's layered well enough that it can be fixed later without radical sirgery. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
Linus Torvalds wrote:
> So for future cases: if there are big independent overhauls of core
> subsystems, I'd really like to see them kept separate, ok?
Since the trusted and encrypted keys that Mimi and Dmitry deal with are also
more akin to the keyring stuff, should they go through the keyring branch?
And does James want to hold that branch?
> Also, David, with (for example) 1700+ new lines in lib/assoc_array.c,
> I would really *really* like code like this to have some review by
> outsiders. Maybe you did have that, but I saw absolutely no sign of it
> in the tree when I merged it. That code alone made me go "Hmm, where
> did this come from, how was it tested, why should I merge it?".
I wrote it in userspace where I could easily drive it with huge numbers of
entries (add a million keys, say, delete them randomly and check at each step
that each remaining key can still be found) and also valground it. For
reference, what's the best way of showing you something like this? I could
include it in the commit message, but the driver is actually fairly large.
Since it went through James's tree in the middle of a pile of patches, it
would be awkward for you to then discard that information to trim things.
I did show it to Paul McKenney - and he gave me some comments on it, though I
didn't ask for a Reviewed-by line, which in retrospect I should've done.
> I do see *some* minimal comments on it from George Spelvin on lkml. I don't
> see any sign of that in the commit messages, though.
Should we have a "Comments-from: x " line for this? So that people who
made comments but don't want to say they've properly reviewed it can be
recognised formally?
I'd prefer to avoid adding changelogs into the patch description - though
maybe that's the best way to do this.
> I'd also see no comments on where the algorithm came from etc.
The basic algorithm was actually something I came up with myself to use on
disk in one of the earliest implementations of fscache that I tried. I then
adapted it to this. I suspected that I couldn't've been the only one to have
thought this up, so I asked Paul to take a peek at the code and see what he
thought.
> It clearly has subtle memory ordering (smp_read_barrier_depends() etc),
Actually, it's just where I'm doing RCU-type stuff. There's an argument I
should be using the RCU functions anyway, but:
(1) A flag would have to be passed down to say whether the callers of the
assoc_array functions are holding the write lock or whether they're
dependent on the RCU readlock - at least for the iterate and find
functions. I suppose this flag would be ignored if LOCKDEP=n though the
parameter would still have to exist.
(2) Sometimes I want to read the pointers in a node and examine bit 0 (which
is a tag to indicate metadata or leaf) and then decide what to do based
on that. I don't want to interpolate a barrier there unless I'm actually
going to follow the pointer and I don't want to have to read the pointer
value again if I've determined it is what I'm looking for. For example:
struct assoc_array_node *n1 = ...;
struct assoc_array_node *n2 = rcu_access_pointer(n1->slots[x]);
/* Did an ACCESS_ONCE() */
if (is_bit0_set(n2)) {
/* Now we need a barrier */
n2 = rcu_dereference_check(n1->slots[x], check);
/* Did another ACCESS_ONCE() */
}
(3) I'm using the undefined struct assoc_array_ptr to prevent accidental
dereferences of tagged pointers in the tree. Either Sparse or GCC will
throw a errors if these are passed to rcu functions, depending on how you
do it.
> In short: this is exactly the kind of thing I *don't* enjoy merging,
> because the code that needed review was
>
> - mixed up with other changes that had nothing to do with it
> - had no pointers to help me review it
> - had zero information about others who had possibly reviewed it before
>
> and quite frankly, without the extended explanation of what the
> changes were for (which I also didn't get initially), I'd probably
> have decided half-way that it's not worth the headache.
Is there some way in the GIT repo to associate an 'extended explanation' with
several patches?
> In the end, the code didn't look bad, and I didn't find any obvious
> problems, but there's very much a reason why I merged this over two
> weeks after the first pull request was originally sent to me.
>
> So guys, make it easier for me to merge these kinds of things, and
> *don't* do what happened this time. Ok? Pretty please?
Ok.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, Nov 21, 2013 at 11:22 PM, Linus Torvalds wrote: > In short: this is exactly the kind of thing I *don't* enjoy merging, > because the code that needed review was > > - mixed up with other changes that had nothing to do with it > - had no pointers to help me review it > - had zero information about others who had possibly reviewed it before > > and quite frankly, without the extended explanation of what the > changes were for (which I also didn't get initially), I'd probably > have decided half-way that it's not worth the headache. > > In the end, the code didn't look bad, and I didn't find any obvious > problems, but there's very much a reason why I merged this over two > weeks after the first pull request was originally sent to me. > > So guys, make it easier for me to merge these kinds of things, and > *don't* do what happened this time. Ok? Pretty please? If it makes you feel any more confident, we've been carrying the keys code during the development of Fedora 20 (and rawhide) as patches. They were needed to solve some issues some of the userspace people were seeing that David mentioned in his explanation. The issues that have cropped up were all fixed in the various follow up commits included in the pull and we haven't hit any others that I'm aware of. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, 21 Nov 2013, Linus Torvalds wrote: > So for future cases: if there are big independent overhauls of core > subsystems, I'd really like to see them kept separate, ok? Yep. > So guys, make it easier for me to merge these kinds of things, and > *don't* do what happened this time. Ok? Pretty please? Ok. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, 21 Nov 2013, Linus Torvalds wrote: So for future cases: if there are big independent overhauls of core subsystems, I'd really like to see them kept separate, ok? Yep. So guys, make it easier for me to merge these kinds of things, and *don't* do what happened this time. Ok? Pretty please? Ok. -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, Nov 21, 2013 at 11:22 PM, Linus Torvalds torva...@linux-foundation.org wrote: In short: this is exactly the kind of thing I *don't* enjoy merging, because the code that needed review was - mixed up with other changes that had nothing to do with it - had no pointers to help me review it - had zero information about others who had possibly reviewed it before and quite frankly, without the extended explanation of what the changes were for (which I also didn't get initially), I'd probably have decided half-way that it's not worth the headache. In the end, the code didn't look bad, and I didn't find any obvious problems, but there's very much a reason why I merged this over two weeks after the first pull request was originally sent to me. So guys, make it easier for me to merge these kinds of things, and *don't* do what happened this time. Ok? Pretty please? If it makes you feel any more confident, we've been carrying the keys code during the development of Fedora 20 (and rawhide) as patches. They were needed to solve some issues some of the userspace people were seeing that David mentioned in his explanation. The issues that have cropped up were all fixed in the various follow up commits included in the pull and we haven't hit any others that I'm aware of. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
Linus Torvalds torva...@linux-foundation.org wrote:
So for future cases: if there are big independent overhauls of core
subsystems, I'd really like to see them kept separate, ok?
Since the trusted and encrypted keys that Mimi and Dmitry deal with are also
more akin to the keyring stuff, should they go through the keyring branch?
And does James want to hold that branch?
Also, David, with (for example) 1700+ new lines in lib/assoc_array.c,
I would really *really* like code like this to have some review by
outsiders. Maybe you did have that, but I saw absolutely no sign of it
in the tree when I merged it. That code alone made me go Hmm, where
did this come from, how was it tested, why should I merge it?.
I wrote it in userspace where I could easily drive it with huge numbers of
entries (add a million keys, say, delete them randomly and check at each step
that each remaining key can still be found) and also valground it. For
reference, what's the best way of showing you something like this? I could
include it in the commit message, but the driver is actually fairly large.
Since it went through James's tree in the middle of a pile of patches, it
would be awkward for you to then discard that information to trim things.
I did show it to Paul McKenney - and he gave me some comments on it, though I
didn't ask for a Reviewed-by line, which in retrospect I should've done.
I do see *some* minimal comments on it from George Spelvin on lkml. I don't
see any sign of that in the commit messages, though.
Should we have a Comments-from: x y@z line for this? So that people who
made comments but don't want to say they've properly reviewed it can be
recognised formally?
I'd prefer to avoid adding changelogs into the patch description - though
maybe that's the best way to do this.
I'd also see no comments on where the algorithm came from etc.
The basic algorithm was actually something I came up with myself to use on
disk in one of the earliest implementations of fscache that I tried. I then
adapted it to this. I suspected that I couldn't've been the only one to have
thought this up, so I asked Paul to take a peek at the code and see what he
thought.
It clearly has subtle memory ordering (smp_read_barrier_depends() etc),
Actually, it's just where I'm doing RCU-type stuff. There's an argument I
should be using the RCU functions anyway, but:
(1) A flag would have to be passed down to say whether the callers of the
assoc_array functions are holding the write lock or whether they're
dependent on the RCU readlock - at least for the iterate and find
functions. I suppose this flag would be ignored if LOCKDEP=n though the
parameter would still have to exist.
(2) Sometimes I want to read the pointers in a node and examine bit 0 (which
is a tag to indicate metadata or leaf) and then decide what to do based
on that. I don't want to interpolate a barrier there unless I'm actually
going to follow the pointer and I don't want to have to read the pointer
value again if I've determined it is what I'm looking for. For example:
struct assoc_array_node *n1 = ...;
struct assoc_array_node *n2 = rcu_access_pointer(n1-slots[x]);
/* Did an ACCESS_ONCE() */
if (is_bit0_set(n2)) {
/* Now we need a barrier */
n2 = rcu_dereference_check(n1-slots[x], check);
/* Did another ACCESS_ONCE() */
}
(3) I'm using the undefined struct assoc_array_ptr to prevent accidental
dereferences of tagged pointers in the tree. Either Sparse or GCC will
throw a errors if these are passed to rcu functions, depending on how you
do it.
In short: this is exactly the kind of thing I *don't* enjoy merging,
because the code that needed review was
- mixed up with other changes that had nothing to do with it
- had no pointers to help me review it
- had zero information about others who had possibly reviewed it before
and quite frankly, without the extended explanation of what the
changes were for (which I also didn't get initially), I'd probably
have decided half-way that it's not worth the headache.
Is there some way in the GIT repo to associate an 'extended explanation' with
several patches?
In the end, the code didn't look bad, and I didn't find any obvious
problems, but there's very much a reason why I merged this over two
weeks after the first pull request was originally sent to me.
So guys, make it easier for me to merge these kinds of things, and
*don't* do what happened this time. Ok? Pretty please?
Ok.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Thu, 21 Nov 2013, Linus Torvalds wrote: I do see *some* minimal comments on it from George Spelvin on lkml. I'd like to apologize for dropping the ball on that. I started working on it seriously, but with various emergencies, I've been AFK from lkml for the last month. I'm not really thilled with it; I think the fanout of 16 is low for something with its scale ambitions, and the properties expected of the chunked key access method are not documented as clearly as they should be. The way the key is fiddled the put keyring objects in a contiguous range of the trie is a particularly egregious layering violation. But I am convinced that it's been tested and works; my complaints are in the areas of ugliness and efficiency. And it's layered well enough that it can be fixed later without radical sirgery. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
Also, here's an updated branch to pull from with four new fixes from David. --- The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus2 Anand Avati (1): selinux: consider filesystem subtype in policies Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled Casey Schaufler (2): Smack: Implement lock security mode Smack: Ptrace access check mode Chen Gang (1): kernel/system_certificate.S: use real contents instead of macro GLOBAL() Chris PeBenito (1): Add SELinux policy capability for always checking packet and peer classes. David Howells (33): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Fix a race between negating a key and reading the error set KEYS: Fix keyring quota misaccounting on key replacement and unlink KEYS: The RSA public key algorithm needs to select MPILIB KEYS: Fix UID check in keyctl_get_persistent() KEYS: Fix error handling in big_key instantiation KEYS: Fix keyring content gc scanner Dmitry Kasatkin (11): ima: fix script messages crypto: provide single place for hash algo information keys: change asymmetric keys to use common hash definitions ima: provide support for arbitrary hash algorithms ima: read and use signature hash algorithm ima: pass full xattr with the signature ima: use dynamically allocated hash storage ima: provide dedicated hash algo allocation function ima: support arbitrary hash algorithms in ima_calc_buffer_hash ima: ima_calc_boot_agregate must use SHA1 ima: provide hash algo info in the xattr Duan Jiong (1): selinux: Use kmemdup instead of kmalloc + memcpy Eric Paris (13): SELinux: fix selinuxfs policy file on big endian systems SELinux: remove crazy contortions around proc SELinux: make it harder to get the number of mnt opts wrong SELinux: use define for number of bits in the mnt flags mask SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT SELinux: do all flags twiddling in one place SELinux: renumber the superblock options SELinux: change sbsec->behavior to short SELinux: do not handle seclabel as a special flag SELinux: pass a superblock to security_fs_use SELinux: use a helper function to determine seclabel Revert "SELinux: do not handle seclabel as a special flag" security: remove erroneous comment about capabilities.o link ordering James Morris (3): Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open
Re: [GIT] Security subsystem updates for 3.13
Also, here's an updated branch to pull from with four new fixes from David. --- The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus2 Anand Avati (1): selinux: consider filesystem subtype in policies Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled Casey Schaufler (2): Smack: Implement lock security mode Smack: Ptrace access check mode Chen Gang (1): kernel/system_certificate.S: use real contents instead of macro GLOBAL() Chris PeBenito (1): Add SELinux policy capability for always checking packet and peer classes. David Howells (33): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Fix a race between negating a key and reading the error set KEYS: Fix keyring quota misaccounting on key replacement and unlink KEYS: The RSA public key algorithm needs to select MPILIB KEYS: Fix UID check in keyctl_get_persistent() KEYS: Fix error handling in big_key instantiation KEYS: Fix keyring content gc scanner Dmitry Kasatkin (11): ima: fix script messages crypto: provide single place for hash algo information keys: change asymmetric keys to use common hash definitions ima: provide support for arbitrary hash algorithms ima: read and use signature hash algorithm ima: pass full xattr with the signature ima: use dynamically allocated hash storage ima: provide dedicated hash algo allocation function ima: support arbitrary hash algorithms in ima_calc_buffer_hash ima: ima_calc_boot_agregate must use SHA1 ima: provide hash algo info in the xattr Duan Jiong (1): selinux: Use kmemdup instead of kmalloc + memcpy Eric Paris (13): SELinux: fix selinuxfs policy file on big endian systems SELinux: remove crazy contortions around proc SELinux: make it harder to get the number of mnt opts wrong SELinux: use define for number of bits in the mnt flags mask SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT SELinux: do all flags twiddling in one place SELinux: renumber the superblock options SELinux: change sbsec-behavior to short SELinux: do not handle seclabel as a special flag SELinux: pass a superblock to security_fs_use SELinux: use a helper function to determine seclabel Revert SELinux: do not handle seclabel as a special flag security: remove erroneous comment about capabilities.o link ordering James Morris (3): Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open tpm:
Re: [GIT] Security subsystem updates for 3.13
On Mon, 18 Nov 2013, Linus Torvalds wrote: > On Mon, Nov 18, 2013 at 3:30 PM, James Morris wrote: > > On Mon, 18 Nov 2013, Josh Boyer wrote: > >> > >> Unless I'm missing something, I don't think this has landed in Linus' > >> tree yet. Linus, did this pull request get NAKed or fall through the > >> cracks? > > > > I think Linus is on vacation and merging only sporadically at the moment. > > No,while it is true that I've been traveling, I've also been actively > merging, and no, that pull request isn't lost. > > I don't really like the look of it though (particularly all the magic > new keys changes), so I've been delaying it and merging other regular > stuff that I don't have any issues with. I'm leaving that pull for > later in order to go over it more carefully when I'm not doing fifteen > other pulls the same day.. > > If somebody wants to explain about the rationale new keys code, that might > help. Thanks -- I've cc'd David for comment. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Mon, Nov 18, 2013 at 3:30 PM, James Morris wrote: > On Mon, 18 Nov 2013, Josh Boyer wrote: >> >> Unless I'm missing something, I don't think this has landed in Linus' >> tree yet. Linus, did this pull request get NAKed or fall through the >> cracks? > > I think Linus is on vacation and merging only sporadically at the moment. No,while it is true that I've been traveling, I've also been actively merging, and no, that pull request isn't lost. I don't really like the look of it though (particularly all the magic new keys changes), so I've been delaying it and merging other regular stuff that I don't have any issues with. I'm leaving that pull for later in order to go over it more carefully when I'm not doing fifteen other pulls the same day.. If somebody wants to explain about the rationale new keys code, that might help. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Mon, 18 Nov 2013, Josh Boyer wrote: > On Wed, Nov 6, 2013 at 7:51 PM, James Morris wrote: > > In this patchset, we finally get an SELinux update, with Paul Moore taking > > over as maintainer of that code. > > > > Also a significant update for the Keys subsystem, as well as maintenance > > updates to Smack, IMA, TPM, and Apparmor. > > > > Please pull. > > > > The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: > > > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 > > 06:40:55 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > > for-linus > > Unless I'm missing something, I don't think this has landed in Linus' > tree yet. Linus, did this pull request get NAKed or fall through the > cracks? I think Linus is on vacation and merging only sporadically at the moment. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Mon, 18 Nov 2013, Josh Boyer wrote: On Wed, Nov 6, 2013 at 7:51 PM, James Morris jmor...@namei.org wrote: In this patchset, we finally get an SELinux update, with Paul Moore taking over as maintainer of that code. Also a significant update for the Keys subsystem, as well as maintenance updates to Smack, IMA, TPM, and Apparmor. Please pull. The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Unless I'm missing something, I don't think this has landed in Linus' tree yet. Linus, did this pull request get NAKed or fall through the cracks? I think Linus is on vacation and merging only sporadically at the moment. -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Mon, Nov 18, 2013 at 3:30 PM, James Morris jmor...@namei.org wrote: On Mon, 18 Nov 2013, Josh Boyer wrote: Unless I'm missing something, I don't think this has landed in Linus' tree yet. Linus, did this pull request get NAKed or fall through the cracks? I think Linus is on vacation and merging only sporadically at the moment. No,while it is true that I've been traveling, I've also been actively merging, and no, that pull request isn't lost. I don't really like the look of it though (particularly all the magic new keys changes), so I've been delaying it and merging other regular stuff that I don't have any issues with. I'm leaving that pull for later in order to go over it more carefully when I'm not doing fifteen other pulls the same day.. If somebody wants to explain about the rationale new keys code, that might help. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.13
On Mon, 18 Nov 2013, Linus Torvalds wrote: On Mon, Nov 18, 2013 at 3:30 PM, James Morris jmor...@namei.org wrote: On Mon, 18 Nov 2013, Josh Boyer wrote: Unless I'm missing something, I don't think this has landed in Linus' tree yet. Linus, did this pull request get NAKed or fall through the cracks? I think Linus is on vacation and merging only sporadically at the moment. No,while it is true that I've been traveling, I've also been actively merging, and no, that pull request isn't lost. I don't really like the look of it though (particularly all the magic new keys changes), so I've been delaying it and merging other regular stuff that I don't have any issues with. I'm leaving that pull for later in order to go over it more carefully when I'm not doing fifteen other pulls the same day.. If somebody wants to explain about the rationale new keys code, that might help. Thanks -- I've cc'd David for comment. -- James Morris jmor...@namei.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] Security subsystem updates for 3.13
In this patchset, we finally get an SELinux update, with Paul Moore taking over as maintainer of that code. Also a significant update for the Keys subsystem, as well as maintenance updates to Smack, IMA, TPM, and Apparmor. Please pull. The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Anand Avati (1): selinux: consider filesystem subtype in policies Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled Casey Schaufler (2): Smack: Implement lock security mode Smack: Ptrace access check mode Chen Gang (1): kernel/system_certificate.S: use real contents instead of macro GLOBAL() Chris PeBenito (1): Add SELinux policy capability for always checking packet and peer classes. David Howells (29): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Fix a race between negating a key and reading the error set KEYS: Fix keyring quota misaccounting on key replacement and unlink Dmitry Kasatkin (11): ima: fix script messages crypto: provide single place for hash algo information keys: change asymmetric keys to use common hash definitions ima: provide support for arbitrary hash algorithms ima: read and use signature hash algorithm ima: pass full xattr with the signature ima: use dynamically allocated hash storage ima: provide dedicated hash algo allocation function ima: support arbitrary hash algorithms in ima_calc_buffer_hash ima: ima_calc_boot_agregate must use SHA1 ima: provide hash algo info in the xattr Duan Jiong (1): selinux: Use kmemdup instead of kmalloc + memcpy Eric Paris (13): SELinux: fix selinuxfs policy file on big endian systems SELinux: remove crazy contortions around proc SELinux: make it harder to get the number of mnt opts wrong SELinux: use define for number of bits in the mnt flags mask SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT SELinux: do all flags twiddling in one place SELinux: renumber the superblock options SELinux: change sbsec->behavior to short SELinux: do not handle seclabel as a special flag SELinux: pass a superblock to security_fs_use SELinux: use a helper function to determine seclabel Revert "SELinux: do not handle seclabel as a special flag" security: remove erroneous comment about capabilities.o link ordering James Morris (3): Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open tpm: Remove redundant dev_set_drvdata tpm: st33: Remove
[GIT] Security subsystem updates for 3.13
In this patchset, we finally get an SELinux update, with Paul Moore taking over as maintainer of that code. Also a significant update for the Keys subsystem, as well as maintenance updates to Smack, IMA, TPM, and Apparmor. Please pull. The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Anand Avati (1): selinux: consider filesystem subtype in policies Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled Casey Schaufler (2): Smack: Implement lock security mode Smack: Ptrace access check mode Chen Gang (1): kernel/system_certificate.S: use real contents instead of macro GLOBAL() Chris PeBenito (1): Add SELinux policy capability for always checking packet and peer classes. David Howells (29): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Fix a race between negating a key and reading the error set KEYS: Fix keyring quota misaccounting on key replacement and unlink Dmitry Kasatkin (11): ima: fix script messages crypto: provide single place for hash algo information keys: change asymmetric keys to use common hash definitions ima: provide support for arbitrary hash algorithms ima: read and use signature hash algorithm ima: pass full xattr with the signature ima: use dynamically allocated hash storage ima: provide dedicated hash algo allocation function ima: support arbitrary hash algorithms in ima_calc_buffer_hash ima: ima_calc_boot_agregate must use SHA1 ima: provide hash algo info in the xattr Duan Jiong (1): selinux: Use kmemdup instead of kmalloc + memcpy Eric Paris (13): SELinux: fix selinuxfs policy file on big endian systems SELinux: remove crazy contortions around proc SELinux: make it harder to get the number of mnt opts wrong SELinux: use define for number of bits in the mnt flags mask SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT SELinux: do all flags twiddling in one place SELinux: renumber the superblock options SELinux: change sbsec-behavior to short SELinux: do not handle seclabel as a special flag SELinux: pass a superblock to security_fs_use SELinux: use a helper function to determine seclabel Revert SELinux: do not handle seclabel as a special flag security: remove erroneous comment about capabilities.o link ordering James Morris (3): Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open tpm: Remove redundant dev_set_drvdata tpm: st33: Remove
