Re: [PATCH] X.509: Fix the time validation [ver #3]
Greg Kroah-Hartman wrote: > David, any reason you didn't put a cc: stable in the commit for it to be > picked up in the stable releases? I did cc it to stable. David -- 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 [ver #3]
On Fri, Dec 11, 2015 at 6:13 AM, David Howells wrote: > Greg Kroah-Hartman wrote: > >> David, any reason you didn't put a cc: stable in the commit for it to be >> picked up in the stable releases? > > I did cc it to stable. You had the stable list in the CC field when you sent the patch, but the CC: sta...@vger.kernel.org tag is missing in the commit body. Greg's scripts key off the later. Just cc'ing the list when you send the email does nothing. FWIW, I asked James if it should have been CC'd to stable when he sent the pull request to Linus and I never got a reply. josh -- 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
Exposing secid to secctx mapping to user-space
Hello, I would like to write a patch that would expose, via selinuxfs, the mapping between secids in the kernel and security contexts to user-space, but before doing so wanted to get some feedback as to whether or not such an endeavor could have any support upstream. The direct motivation for this is the desire to communicate calling security ids/contexts over binder IPC on android for use in a user-space object manager. Passing the security ids themselves would be simpler and more efficient in the critical kernel path, but they currently have no user-space meaning. Thank You, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities
On 12/04/2015 05:12 PM, Andy Lutomirski wrote:
> On Fri, Dec 4, 2015 at 7:08 AM, Michael Kerrisk (man-pages)
> wrote:
>> Hi Andy,
>>
>> I have applied your patch (below). Thanks for writing it.
>> But I have a question or two and a request.
>>
>> ===
>>
>> In the capabilities(7) page tehre is the longstanding text:
>>
>>An application can use the following call to lock itself, and
>>all of its descendants, into an environment where the only way
>>of gaining capabilities is by executing a program with associ‐
>>ated file capabilities:
>>
>>prctl(PR_SET_SECUREBITS,
>>SECBIT_KEEP_CAPS_LOCKED |
>>SECBIT_NO_SETUID_FIXUP |
>>SECBIT_NO_SETUID_FIXUP_LOCKED |
>>SECBIT_NOROOT |
>>SECBIT_NOROOT_LOCKED);
>>
>> As far as I can estimate, no changes are needed here to include
>> SECBIT_NO_CAP_AMBIENT_RAISE and SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED
>> in the above prctl() call, but could you confirm please?
>
> Correct. I'll probably write up a patch to suggest that doing this is
> a poor idea on a conventional distro, though, and I'll explain why. I
> suppose than deleting this would be an option, too.
Ping! :-)
>> ===
>>
>> In the message for kernel commit
>> 58319057b7847667f0c9585b9de0e8932b0fdb08
>> you included this text:
>>
>> [[
>> Because capability inheritance is so
>> broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and
>> then calling execve effectively drops capabilities. Therefore,
>> setresuid from root to nonroot conditionally clears pA unless
>> SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can
>> re-add bits to pA afterwards.
>> ]]
>>
>> I'm struggling to understand the significance of this text,
>> especially as your man-pages patch makes no mention of this point.
>>
>> The thing is, that text ("Therefore...") implies that there's
>> something special going on beyond the rules already documented
>> elsewhere. I mean, according to the rules aly documented elsewhere
>> in the page:
>
> Whoops, I forgot to add that to the manpage.
>
>>
>> (1) If a process with UIDs of 0 sets all its UIDs
>> nonzero, then, the permitted and effective sets are cleared
>> (that's the classical behavior), and because the permitted
>> set is cleared, then so is the ambient set.
>>
>> (2) And if we set SECBIT_NO_SETUID_FIXUP then
>> a UID 0 ==> nonzero transition doesn't clear permitted and
>> effective sets, and then of course the ambient set is not
>> cleared.
>>
>> So, what additional point were you meaning to convey in
>> the commit message? (Maybe it was just cruft in the commit
>> message, but if not, can you explain precisely the arguments
>> for setresuid() that are supposed to generate the special
>> behavior described by the above text.)
>
> It's case (1b), which is like (1) but with KEEPCAPS set. The
> permitted set doesn't get cleared, but the ambient set is still
> cleared.
>
> I'll write a manpage patch.
Ping :-)
(Make these separate patches please.)
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing secid to secctx mapping to user-space
On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman wrote: > Hello, > > I would like to write a patch that would expose, via selinuxfs, the > mapping between secids in the kernel and security contexts to > user-space, but before doing so wanted to get some feedback as to > whether or not such an endeavor could have any support upstream. The > direct motivation for this is the desire to communicate calling security > ids/contexts over binder IPC on android for use in a user-space object > manager. Passing the security ids themselves would be simpler and more > efficient in the critical kernel path, but they currently have no > user-space meaning. In general we try to avoid exposing the secid tokens outside the kernel, I view them as an implementation hack designed to make it easier to manage and operate on the security labels in the kernel. I suspect you will hear something very similar from Casey and the other Smack developers. Another consideration is the long standing LSM stacking effort, they have several good reasons for wanting to abolish the secid token, propagating it to userspace would make that all but impossible. While I'm sympathetic to your desire for less complexity and better performance in passing security labels, from a kernel perspective I think we lose too much in exporting the secid tokens outside the LSM. -- paul moore www.paul-moore.com -- 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 leap year handling again and support leap seconds
On Thu, Dec 10, 2015 at 9:40 AM, David Howells wrote: > David Howells wrote: > >> > the leap second support still looks a bit suspect, as mktime64 will convert >> > mm/dd/ HH/MM/60 and mm/dd/ HH/MM+1/00 to the same time64_t, >> > essentially meaning that two different inputs can yield the same output, >> > possibly violating ASN.1 CER and DER rules. >> >> That's a 'bug' in mktime64() not my parsing of the ASN.1. If it's valid >> ASN.1 >> then we should accept it. > > Any thoughts on how to handle this? I really want to push this patch > upstream. > > David I suppose the first question to ask would be, would anything break security-wise if we did relax it? Because if it's fine to relax it, we should. >From how I understand ASN.1, unless we already require CER or DER, we can safely accept non canonical representations. Given this code also calls asn1_ber_decoder, I don't think it expects much canonicality to begin with. This would mean we can also safely support leap seconds and the 24:00:00 representation. Signature checking is also done against the TBS data in the form as supplied by the caller, and not against a re-serialized timestamp. Thus the timestamp conversion not being injective at least doesn't SEEM like an issue. What seems to confirm this is that there is currently no kernel code that can serialize a time64_t into ASN1_UNITIM - and if there is no such code to begin with, I can't see how non-injecitivity could be a problem. So I'd say: go ahead, but also support 24:00:00 while at it. Possibly add a comment that the time parsing isn't injective so nobody in the future expects it to be. Best regards, Rudolf Polzer -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing secid to secctx mapping to user-space
On 12/11/2015 10:37 AM, Daniel Cashman wrote: > Hello, > > I would like to write a patch that would expose, via selinuxfs, the > mapping between secids in the kernel and security contexts to > user-space, but before doing so wanted to get some feedback as to > whether or not such an endeavor could have any support upstream. Please abandon this. > The > direct motivation for this is the desire to communicate calling security > ids/contexts over binder IPC on android for use in a user-space object > manager. Passing the security ids themselves would be simpler and more > efficient in the critical kernel path, but they currently have no > user-space meaning. The security module infrastructure makes no guarantees about secids. A security module is not required to maintain a persistent relationship between the secid and a particular secctx. SELinux does maintain a persistent relationship, but I don't believe that there is any desire to commit to everything associated with exposing that. Binder ought to have access to more than the secid of the processes and objects involved. Look into the possibilities there before you take this approach. > > Thank You, > Dan > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exposing secid to secctx mapping to user-space
> -Original Message-
> From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-
> security-mod...@vger.kernel.org] On Behalf Of Paul Moore
> Sent: Friday, December 11, 2015 11:55 AM
> To: Daniel Cashman
> Cc: seli...@tycho.nsa.gov; Stephen Smalley ; Eric Paris
> ; James Morris ;
> se...@hallyn.com; linux-security-module@vger.kernel.org; je...@google.com;
> n...@google.com; a...@google.com
> Subject: Re: Exposing secid to secctx mapping to user-space
>
> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman
> wrote:
> > Hello,
> >
> > I would like to write a patch that would expose, via selinuxfs, the
> > mapping between secids in the kernel and security contexts to
> > user-space, but before doing so wanted to get some feedback as to
> > whether or not such an endeavor could have any support upstream. The
> > direct motivation for this is the desire to communicate calling
> > security ids/contexts over binder IPC on android for use in a
> > user-space object manager. Passing the security ids themselves would
> > be simpler and more efficient in the critical kernel path, but they
> > currently have no user-space meaning.
>
> In general we try to avoid exposing the secid tokens outside the kernel, I
> view
> them as an implementation hack designed to make it easier to manage and
> operate on the security labels in the kernel. I suspect you will hear
> something
> very similar from Casey and the other Smack developers. Another consideration
> is the long standing LSM stacking effort, they have several good reasons for
> wanting to abolish the secid token, propagating it to userspace would make
> that
> all but impossible.
>
> While I'm sympathetic to your desire for less complexity and better
> performance
> in passing security labels, from a kernel perspective I think we lose too
> much in
> exporting the secid tokens outside the LSM.
>
I looked at doing the same thing a while back, and pretty much came to the same
conclusion
as Paul as mentioning here. I wanted to do this for sdcardd as part of the fuse
struct. Since
the security pointer is opaque outside of the LSM, it makes it difficult to
transfer this information.
However, could you just tag on something similar to how SO_PEERSEC works to the
binder transaction?
> --
> paul moore
> www.paul-moore.com
> --
> 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
N�r��yb�X��ǧv�^�){.n�+{���.�+r��n�觶��ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
Re: Exposing secid to secctx mapping to user-space
On 12/11/2015 02:55 PM, Paul Moore wrote: On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman wrote: Hello, I would like to write a patch that would expose, via selinuxfs, the mapping between secids in the kernel and security contexts to user-space, but before doing so wanted to get some feedback as to whether or not such an endeavor could have any support upstream. The direct motivation for this is the desire to communicate calling security ids/contexts over binder IPC on android for use in a user-space object manager. Passing the security ids themselves would be simpler and more efficient in the critical kernel path, but they currently have no user-space meaning. In general we try to avoid exposing the secid tokens outside the kernel, I view them as an implementation hack designed to make it easier to manage and operate on the security labels in the kernel. I suspect you will hear something very similar from Casey and the other Smack developers. Another consideration is the long standing LSM stacking effort, they have several good reasons for wanting to abolish the secid token, propagating it to userspace would make that all but impossible. While I'm sympathetic to your desire for less complexity and better performance in passing security labels, from a kernel perspective I think we lose too much in exporting the secid tokens outside the LSM. To clarify, security identifiers were by design provided in the Flask architecture and SELinux as lightweight, non-persistent handles to security contexts, and exposed to userspace by the original SELinux API (pre-2.6, of course). They were only removed when we transitioned to using extended attributes and the xattr API for file security labels, and we made all of the other APIs consistent as passing context strings seemed acceptable for proc and selinuxfs as well. There was some thought to turning SIDs into proper reference-counted objects or even wrapping them with descriptors so that their lifecycles could be fully managed by the kernel, but that never happened. Passing a security context string on every binder IPC may be too costly from a performance point of view (numbers would be helpful here). I think this situation differs from that of stream sockets (i.e. getsockopt SO_PEERSEC), since they are looking at enabling passing of sender security label for every binder IPC (not just specific applications) and since binder IPC is quite different from stream socket IPC in its semantics and its performance. Perhaps we could provide a new fixed-size tokenized version of the security context string for export to userspace that could be embedded in the binder transaction structure? This could avoid both the limitations of the current secid (e.g. limited to 32 bits, no stackability) and the overhead of copying context strings on every IPC. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing secid to secctx mapping to user-space
On 12/11/2015 2:14 PM, Stephen Smalley wrote: > On 12/11/2015 02:55 PM, Paul Moore wrote: >> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman wrote: >>> Hello, >>> >>> I would like to write a patch that would expose, via selinuxfs, the >>> mapping between secids in the kernel and security contexts to >>> user-space, but before doing so wanted to get some feedback as to >>> whether or not such an endeavor could have any support upstream. The >>> direct motivation for this is the desire to communicate calling security >>> ids/contexts over binder IPC on android for use in a user-space object >>> manager. Passing the security ids themselves would be simpler and more >>> efficient in the critical kernel path, but they currently have no >>> user-space meaning. >> >> In general we try to avoid exposing the secid tokens outside the >> kernel, I view them as an implementation hack designed to make it >> easier to manage and operate on the security labels in the kernel. I >> suspect you will hear something very similar from Casey and the other >> Smack developers. Another consideration is the long standing LSM >> stacking effort, they have several good reasons for wanting to abolish >> the secid token, propagating it to userspace would make that all but >> impossible. >> >> While I'm sympathetic to your desire for less complexity and better >> performance in passing security labels, from a kernel perspective I >> think we lose too much in exporting the secid tokens outside the LSM. > > To clarify, security identifiers were by design provided in the Flask > architecture and SELinux as lightweight, non-persistent handles to security > contexts, and exposed to userspace by the original SELinux API (pre-2.6, of > course). They were only removed when we transitioned to using extended > attributes and the xattr API for file security labels, and we made all of the > other APIs consistent as passing context strings seemed acceptable for proc > and selinuxfs as well. There was some thought to turning SIDs into proper > reference-counted objects or even wrapping them with descriptors so that > their lifecycles could be fully managed by the kernel, but that never > happened. > > Passing a security context string on every binder IPC may be too costly from > a performance point of view (numbers would be helpful here). I think this > situation differs from that of stream sockets (i.e. getsockopt SO_PEERSEC), > since they are looking at enabling passing of sender security label for every > binder IPC (not just specific applications) and since binder IPC is quite > different from stream socket IPC in its semantics and its performance. It seems to me that a better approach might be for the object manager to tell the binder driver about its security constraints and have the binder driver do the check in the kernel. I realize that could require additional LSM hooks (just like kdbus) but I think you may be looking at that anyway, unless you're convinced binder will only ever work with SELinux. > > Perhaps we could provide a new fixed-size tokenized version of the security > context string for export to userspace that could be embedded in the binder > transaction structure? This could avoid both the limitations of the current > secid (e.g. limited to 32 bits, no stackability) and the overhead of copying > context strings on every IPC. How about this: Provide an alias mechanism for secctx. There would then be a secid (32bits) a secctx (arbitrary text string) and a secalias which could be a limited string of some length. You could use the alias in place of the secctx anywhere you liked. You would always use the secalais in binder communications. The advantage is that the kernel would know that "#fish" was an alias for "Raygun_t:s27", just like the object manager. The other, longer term, advantage is that when (if?) we get to extreme module stacking we'll have a mechanism for dealing with a secctx like . security_secctx_to_secalias(), security_secalias_to_secctx(). There might be other kernel functions as well. I'd like to see the secalias defined by the LSM infrastructure rather than each module, but I think we could get agreement reasonably quickly. An eight character string beginning with "#" as a strawman proposal. /sys/fs/lsmfs/alais # echo 'Raygun_t:s27 #fish' > /sys/fs/lsmfs/alias lsmfs would call security_alias_secctx(char *secctx, char *secalias) to set the alais. I suspect you could put it in the SELinux policy somehow, although the kernel wouldn't care about it and could leave it up to the user space to set it. Just a Friday afternoon sort of thought. > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to major
