Re: Exposing secid to secctx mapping to user-space
On Tue, Dec 15, 2015 at 3:58 PM, Daniel Cashmanwrote: > On 12/15/2015 07:00 AM, Stephen Smalley wrote: >> 1. I don't think it is the size of the context that is the concern but >> rather the fact that it is a variable-length string, whereas current >> binder commands use fixed-size arguments and encode the size in the >> command value (common for ioctls). Supporting passing a variable-length >> string would be a change to the protocol and would complicate the code. >> On the performance side, it means generating a context string from the >> secid and then copying it to userspace on each IPC (versus just getting >> the secid and putting that in the existing binder_transaction_data that >> is already copied to userspace). > > This is precisely the motivation for the original enquiry. Issue has > been brought up about changing the protocol, and concern has also been > strongly expressed about the overhead introduced by the string > operations, although this has not been measured. User-space would still > need to do something intelligent with the secid, which would involve its > own lookup and caching, but the idea is that this wouldn't be done with > the binder lock held. > >> 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks >> might exist with and without the current patch that copies the context >> string. > > Yes, this needs to be done. This issue was brought up as part of > discussion regarding a proposed change to the binder driver to add the > context string to each transaction. An outcome of that discussion was, > "before we go too far into this, let's see the reaction upstream to > exposing the secid." Based on the reaction here (upstream), I think > it's my responsibility to push forward the string-based change and get > the appropriate perf numbers so that a meaningful comparison can be made. The existing, variable length string based approach is going to be your easiest path forward with respect to the kernel, although it may turn out to be a non-starter from a binder point of view. I just want to reiterate that I'm not against the idea of exposing the secid tokens, but not necessarily in their current form; we will probably want to revisit the idea of a persistent secid and consider the impact to any future stacking work. -- 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: Exposing secid to secctx mapping to user-space
On Tue, Dec 15, 2015 at 2:09 PM, Joe Nallwrote: >> On Dec 15, 2015, at 12:03 PM, Stephen Smalley wrote: >> Are you patching the kernel to support > 4K contexts? >> Otherwise, I'd expect you run up against the proc and selinuxfs API >> limitations (page size) and/or the filesystem xattr storage limitations >> (block size). > > No. The example was a contrived example of what is possible within the > format. We use a couple of 2500 byte labels in formal test these days to make > sure that we don't have an OS regression. I just get tired of code like this > in openswan: > > #ifdef HAVE_LABELED_IPSEC > /* security label length should not exceed 256 in most cases, > * (discussed with kernel and selinux people). > */ > #define MAX_SECCTX_LEN257 /* including '\0'*/ So let's just get rid of labeled IPsec ... show of hands? ;) -- 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: Exposing secid to secctx mapping to user-space
On 12/15/2015 11:06 AM, Casey Schaufler wrote: On 12/15/2015 7:00 AM, Stephen Smalley wrote: On 12/14/2015 05:57 PM, Roberts, William C wrote: If I understand correctly, the goal here is to avoid the lookup from pid to context. If we somehow Had the context or a token to a context during the ipc transaction to userspace, we could just use that In computing the access decision. If that is correct, then since we have PID, why not just extend the SE Linux compute av decision interface to support passing of PID and then it can do the lookup in the Kernel? That's no less racy than getpidcon(). I got a bounce from when I sent this from gmail, resending. True, but in this case the binder transaction would be dead... Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big. grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' { thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen} END { printf("average: %dn", totlen/NR); } ' The avg type length for domain types in external/sepolicy is 7. Add the full ctx: u:r:xxx:s0(cat) 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"? 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough? 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips. 1. I don't think it is the size of the context that is the concern but rather the fact that it is a variable-length string, whereas current binder commands use fixed-size arguments and encode the size in the command value (common for ioctls). Supporting passing a variable-length string would be a change to the protocol and would complicate the code. On the performance side, it means generating a context string from the secid and then copying it to userspace on each IPC (versus just getting the secid and putting that in the existing binder_transaction_data that is already copied to userspace). I have long wondered why SELinux generates the context string of the secid more than once. Audit performance alone would justify keeping it around. The variable length issue isn't so difficult as you make it out. As William pointed out earlier, most SELinux contexts are short. Two protocols, one with a fixed length of 16 chars (typical is 7) and one with a fixed length of 256 (for abnormal contexts) solve the problem without complicating the code hardly at all. If it's such a problem, why do we have SO_PEERSEC return a variable length string? That's been around forever and seems to work just fine. Generating an audit record means you are already on the slow path, so adding the cost of generating a context at that point shouldn't be significant (but if one has performance data to the contrary, that would always be of interest). Keeping complete context strings in kernel memory at all times wasn't viewed as desirable, particularly when you consider the next point. There is no internal limit on SELinux context size and one can in fact generate a SELinux context string that exceeds 256 bytes (just create a category set with many different, non-contiguous categories, e.g. a category set with every other category), so you can't just pick a couple of sizes (16 and 256 in your example) and be done with it. It may be unusual to exceed 256 but it isn't impossible, and users of MLS systems have in fact run up against even the page size limitations of the /proc/self/attr interfaces as a pain point. getsockopt SO_PEERSEC, as I mentioned earlier, is for stream sockets, so you are dealing with a connection-oriented model (with its attendant baseline overhead), server applications opt into getting the security label after the connection is established via getsockopt (which means that the overhead is not imposed on all connections, and which provides a straightforward way of passing variable-length data already), and all of the payload data is typically being copied through the kernel (to and from socket buffers). With binder, we are talking about a synchronous IPC mechanism where the kernel copies the sender information (currently PID and UID) to the receiver on every IPC, the protocol currently passes no variable-length data, and the data is copied directly from the sender's memory into kernel-managed buffers that are mapped read-only into the receiver. So introducing variable-length string copy to binder is a more substantial change, and the baseline performance characteristics and thus the
Re: Exposing secid to secctx mapping to user-space
On 12/15/2015 12:19 PM, Joe Nall wrote: On Dec 15, 2015, at 10:06 AM, Casey Schauflerwrote: ... I have long wondered why SELinux generates the context string of the secid more than once. Audit performance alone would justify keeping it around. The variable length issue isn't so difficult as you make it out. As William pointed out earlier, most SELinux contexts are short. Two protocols, one with a fixed length of 16 chars (typical is 7) and one with a fixed length of 256 (for abnormal contexts) solve the problem without complicating the code hardly at all. We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is possible, though unlikely, to see raw contexts over 5k bytes with 1024 category bits. Thinking like this broke the original RHEL 5 racoon and more recently RHEL 6 openswan for us. joe system_u:system_r:silly_test_t:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c4 0 6,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c 8 06,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020,c1022:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196, c 198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c406,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596 ,
Re: Exposing secid to secctx mapping to user-space
> On Dec 15, 2015, at 10:06 AM, Casey Schauflerwrote: > > ... > I have long wondered why SELinux generates the context string > of the secid more than once. Audit performance alone would > justify keeping it around. The variable length issue isn't > so difficult as you make it out. As William pointed out earlier, > most SELinux contexts are short. Two protocols, one with a > fixed length of 16 chars (typical is 7) and one with a fixed > length of 256 (for abnormal contexts) solve the problem without > complicating the code hardly at all. We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is possible, though unlikely, to see raw contexts over 5k bytes with 1024 category bits. Thinking like this broke the original RHEL 5 racoon and more recently RHEL 6 openswan for us. joe
Re: Exposing secid to secctx mapping to user-space
On 12/15/2015 8:55 AM, Stephen Smalley wrote: > On 12/15/2015 11:06 AM, Casey Schaufler wrote: >> On 12/15/2015 7:00 AM, Stephen Smalley wrote: >>> On 12/14/2015 05:57 PM, Roberts, William C wrote: >> >> If I understand correctly, the goal here is to avoid the lookup from >> pid to context. If we somehow Had the context or a token to a context >> during the ipc transaction to userspace, we could just use that In >> computing the access decision. If that is correct, then since we have >> PID, why not just extend the SE Linux compute av decision interface to >> support > passing of PID and then it can do the lookup in the Kernel? > > That's no less racy than getpidcon(). > I got a bounce from when I sent this from gmail, resending. True, but in this case the binder transaction would be dead... Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big. grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' { thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen} END { printf("average: %dn", totlen/NR); } ' The avg type length for domain types in external/sepolicy is 7. Add the full ctx: u:r:xxx:s0(cat) 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"? 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough? 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips. >>> >>> 1. I don't think it is the size of the context that is the concern but >>> rather the fact that it is a variable-length string, whereas current binder >>> commands use fixed-size arguments and encode the size in the command value >>> (common for ioctls). Supporting passing a variable-length string would be >>> a change to the protocol and would complicate the code. On the performance >>> side, it means generating a context string from the secid and then copying >>> it to userspace on each IPC (versus just getting the secid and putting that >>> in the existing binder_transaction_data that is already copied to >>> userspace). >> >> I have long wondered why SELinux generates the context string >> of the secid more than once. Audit performance alone would >> justify keeping it around. The variable length issue isn't >> so difficult as you make it out. As William pointed out earlier, >> most SELinux contexts are short. Two protocols, one with a >> fixed length of 16 chars (typical is 7) and one with a fixed >> length of 256 (for abnormal contexts) solve the problem without >> complicating the code hardly at all. >> >> If it's such a problem, why do we have SO_PEERSEC return a >> variable length string? That's been around forever and seems >> to work just fine. > > Generating an audit record means you are already on the slow path, so adding > the cost of generating a context at that point shouldn't be significant (but > if one has performance data to the contrary, that would always be of > interest). Keeping complete context strings in kernel memory at all times > wasn't viewed as desirable, particularly when you consider the next point. Making a slow path slower doesn't seem like a great idea to me. The performance of audit is a major impediment to its use. There are some cases where I can see regenerating the context on demand as an optimization, but never in a case where the system regularly exports them. > > There is no internal limit on SELinux context size and one can in fact > generate a SELinux context string that exceeds 256 bytes (just create a > category set with many different, non-contiguous categories, e.g. a category > set with every other category), so you can't just pick a couple of sizes (16 > and 256 in your example) and be done with it. It may be unusual to exceed > 256 but it isn't impossible, and users of MLS systems have in fact run up > against even the page size limitations of the /proc/self/attr interfaces as a > pain point. My secalias suggestion could help here. :) You're right. You'd still need an arbitrary size string protocol. But I expect that binder using (i.e. Android) systems aren't going wild with multiple category MLS (or MCS). Use of that protocol would be sufficiently rare that finding non-artificial test cases would be a challenge. > > getsockopt SO_PEERSEC, as I mentioned earlier, is for
Re: Exposing secid to secctx mapping to user-space
> On Dec 15, 2015, at 12:03 PM, Stephen Smalleywrote: > > On 12/15/2015 12:19 PM, Joe Nall wrote: >> >>> On Dec 15, 2015, at 10:06 AM, Casey Schaufler >>> wrote: >>> >>> ... >>> I have long wondered why SELinux generates the context string >>> of the secid more than once. Audit performance alone would >>> justify keeping it around. The variable length issue isn't >>> so difficult as you make it out. As William pointed out earlier, >>> most SELinux contexts are short. Two protocols, one with a >>> fixed length of 16 chars (typical is 7) and one with a fixed >>> length of 256 (for abnormal contexts) solve the problem without >>> complicating the code hardly at all. >> >> We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is >> possible, though unlikely, to see raw contexts over 5k bytes with 1024 >> category bits. Thinking like this broke the original RHEL 5 racoon and more >> recently RHEL 6 openswan for us. >> >> joe >> >> system_u:system_r:silly_test_t:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c40 > 6,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c8 > 06,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020,c1022:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c >
Re: Exposing secid to secctx mapping to user-space
On 12/15/2015 07:00 AM, Stephen Smalley wrote: > On 12/14/2015 05:57 PM, Roberts, William C wrote: >> If I understand correctly, the goal here is to avoid the lookup from pid to context. If we somehow Had the context or a token to a context during the ipc transaction to userspace, we could just use that In computing the access decision. If that is correct, then since we have PID, why not just extend the SE Linux compute av decision interface to support >>> passing of PID and then it can do the lookup in the Kernel? >>> >>> That's no less racy than getpidcon(). >>> >> >> I got a bounce from when I sent this from gmail, resending. >> >> True, but in this case the binder transaction would be dead... >> >> Why not just pass ctx? It's less than ideal, but it might be good >> enough for now until contexts get unwieldy big. >> >> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | >> awk ' { thislen=length($0); printf("%-5s %dn", NR, thislen); >> totlen+=thislen} >> END { printf("average: %dn", totlen/NR); } ' >> >> The avg type length for domain types in external/sepolicy is 7. Add >> the full ctx: >> >> u:r:xxx:s0(cat) >> >> 1. We're looking at like 18 or so bytes, how do we know this won't be >> "fast enough"? >> 2. What's the current perf numbers, and what's agreed upon on what you >> need to hit to be fast enough? >> 3. I'm assuming the use case is in service manager, but would a >> userspace cache of AVD's help? Then you can (possibly) avoid both >> kernel trips, and you can invalidate the cache on policy reload and on >> PID deaths? In the case of service manager would it always be a miss >> based on usage pattern? I'm assuming things would say hey resolve this >> once, and be done. However, you could only do the ctx lookup and do >> the avd based on the policy in user space, thus avoiding 1 of two trips. > > 1. I don't think it is the size of the context that is the concern but > rather the fact that it is a variable-length string, whereas current > binder commands use fixed-size arguments and encode the size in the > command value (common for ioctls). Supporting passing a variable-length > string would be a change to the protocol and would complicate the code. > On the performance side, it means generating a context string from the > secid and then copying it to userspace on each IPC (versus just getting > the secid and putting that in the existing binder_transaction_data that > is already copied to userspace). This is precisely the motivation for the original enquiry. Issue has been brought up about changing the protocol, and concern has also been strongly expressed about the overhead introduced by the string operations, although this has not been measured. User-space would still need to do something intelligent with the secid, which would involve its own lookup and caching, but the idea is that this wouldn't be done with the binder lock held. > 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks > might exist with and without the current patch that copies the context > string. Yes, this needs to be done. This issue was brought up as part of discussion regarding a proposed change to the binder driver to add the context string to each transaction. An outcome of that discussion was, "before we go too far into this, let's see the reaction upstream to exposing the secid." Based on the reaction here (upstream), I think it's my responsibility to push forward the string-based change and get the appropriate perf numbers so that a meaningful comparison can be made. > 3. It is for any binder-based service that wants to apply SELinux access > checks, which presently includes servicemanager and keystore. > We already have a userspace AVC (in libselinux) that gets used > automatically when you use selinux_check_access(), but you still need to > get the sender security context in some manner. > The issue this hopes to address is passing the secctx along with a binder transaction so that userspace can use it for any access appropriate access controls. Specifically, at the moment, I'm hoping to use the receiving process's concept of which service is being invoked and what the transaction code represents (neither of which the binder driver itself has any concept) to create an SELinux object manager that filters service method calls. This could be seen as a more general implementation of the keystore service object manager. The getpidcon() and SO_PEERSEC type solutions are, as Stephen pointed out, racy such that a process could have changed its context in the interim, but also such that they do not address one-way binder transactions, in which a process could fire of a request and die before it gets processed. This isn't an issue for the servicemanager's current object manager, but could be an issue for other services. Thank You, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
Re: Exposing secid to secctx mapping to user-space
On 12/14/2015 05:57 PM, Roberts, William C wrote: If I understand correctly, the goal here is to avoid the lookup from pid to context. If we somehow Had the context or a token to a context during the ipc transaction to userspace, we could just use that In computing the access decision. If that is correct, then since we have PID, why not just extend the SE Linux compute av decision interface to support passing of PID and then it can do the lookup in the Kernel? That's no less racy than getpidcon(). I got a bounce from when I sent this from gmail, resending. True, but in this case the binder transaction would be dead... Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big. grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' { thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen} END { printf("average: %dn", totlen/NR); } ' The avg type length for domain types in external/sepolicy is 7. Add the full ctx: u:r:xxx:s0(cat) 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"? 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough? 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips. 1. I don't think it is the size of the context that is the concern but rather the fact that it is a variable-length string, whereas current binder commands use fixed-size arguments and encode the size in the command value (common for ioctls). Supporting passing a variable-length string would be a change to the protocol and would complicate the code. On the performance side, it means generating a context string from the secid and then copying it to userspace on each IPC (versus just getting the secid and putting that in the existing binder_transaction_data that is already copied to userspace). 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks might exist with and without the current patch that copies the context string. 3. It is for any binder-based service that wants to apply SELinux access checks, which presently includes servicemanager and keystore. We already have a userspace AVC (in libselinux) that gets used automatically when you use selinux_check_access(), but you still need to get the sender security context in some manner. -- 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/14/2015 12:03 PM, Mike Palmiotto wrote: On Sun, Dec 13, 2015 at 5:06 PM, Paul Moorewrote: On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: Perhaps we could provide a new fixed-size tokenized version of the security context string for export to userspace that could be embedded in the binder transaction structure? This could avoid both the limitations of the current secid (e.g. limited to 32 bits, no stackability) and the overhead of copying context strings on every IPC. On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: How about this: Provide an alias mechanism for secctx. There would then be a secid (32bits) a secctx (arbitrary text string) and a secalias which could be a limited string of some length. You could use the alias in place of the secctx anywhere you liked. My initial reaction to the secalias idea isn't overly positive. It seems like a kludge with a lot of duplication, both in terms of code and concept, and a lot of risk for confusion both by users and policy writers. I think if we really wanted to limit the security label string format to a small size we should have done that from the start, it's too late now. Assuming we see some binder performance numbers, and the numbers are bad, I'm a little more open to doing something with the secid token. Up to this point we haven't made any guarantees about the token and we haven't exported it outside the kernel so there is some ability to change it to fit our needs. Granted, this isn't perfect solution either, and perhaps ultimately we would need something else, but I think it is worth looking into this first before we introduce another string label. Agreed here. I can definitely see a use for security identifier tokens in SE Postgres as well. Ideally these tokens would be 32 bit uints as opposed to shorter string aliases. The userspace AVC provides its own SID mapping (man avc_context_to_sid, avc_has_perm), but that mapping is process-local (unlike kernel SIDs, which are global) and non-persistent (like kernel SIDs, which also aren't guaranteed to remain stable across reboot). That's what is conventionally used by userspace object managers like dbus-daemon, Xorg/XSELinux, and SE-Postgres (although IIRC SE-Postgres rolled their own custom AVC in order to optimize it specifically for their needs). Those SIDs can be used for in-core objects, but you still need to store the security context strings for persistent objects, although you can obviously store each unique one only once and maintain your own indices (ala the persistent SIDs of the Flask and original SELinux labeled filesystem implementation). -- 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 Sun, Dec 13, 2015 at 5:06 PM, Paul Moorewrote: > On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: >> Perhaps we could provide a new fixed-size tokenized version of the >> security context string for export to userspace that could be embedded >> in the binder transaction structure? This could avoid both the >> limitations of the current secid (e.g. limited to 32 bits, no >> stackability) and the overhead of copying context strings on every IPC. > > On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: >> How about this: Provide an alias mechanism for secctx. There would then >> be a secid (32bits) a secctx (arbitrary text string) and a secalias which >> could be a limited string of some length. You could use the alias in place >> of the secctx anywhere you liked. > > My initial reaction to the secalias idea isn't overly positive. It seems like > a kludge with a lot of duplication, both in terms of code and concept, and a > lot of risk for confusion both by users and policy writers. I think if we > really wanted to limit the security label string format to a small size we > should have done that from the start, it's too late now. > > Assuming we see some binder performance numbers, and the numbers are bad, I'm > a little more open to doing something with the secid token. Up to this point > we haven't made any guarantees about the token and we haven't exported it > outside the kernel so there is some ability to change it to fit our needs. > Granted, this isn't perfect solution either, and perhaps ultimately we would > need something else, but I think it is worth looking into this first before we > introduce another string label. Agreed here. I can definitely see a use for security identifier tokens in SE Postgres as well. Ideally these tokens would be 32 bit uints as opposed to shorter string aliases. --Mike > > -- > paul moore > www.paul-moore.com > > ___ > Selinux mailing list > seli...@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exposing secid to secctx mapping to user-space
On 12/14/2015 9:03 AM, Mike Palmiotto wrote: > On Sun, Dec 13, 2015 at 5:06 PM, Paul Moorewrote: >> On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: >>> Perhaps we could provide a new fixed-size tokenized version of the >>> security context string for export to userspace that could be embedded >>> in the binder transaction structure? This could avoid both the >>> limitations of the current secid (e.g. limited to 32 bits, no >>> stackability) and the overhead of copying context strings on every IPC. >> On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: >>> How about this: Provide an alias mechanism for secctx. There would then >>> be a secid (32bits) a secctx (arbitrary text string) and a secalias which >>> could be a limited string of some length. You could use the alias in place >>> of the secctx anywhere you liked. >> My initial reaction to the secalias idea isn't overly positive. It seems >> like >> a kludge with a lot of duplication, both in terms of code and concept, and a >> lot of risk for confusion both by users and policy writers. I think if we >> really wanted to limit the security label string format to a small size we >> should have done that from the start, it's too late now. >> >> Assuming we see some binder performance numbers, and the numbers are bad, I'm >> a little more open to doing something with the secid token. Up to this point >> we haven't made any guarantees about the token and we haven't exported it >> outside the kernel so there is some ability to change it to fit our needs. >> Granted, this isn't perfect solution either, and perhaps ultimately we would >> need something else, but I think it is worth looking into this first before >> we >> introduce another string label. > Agreed here. I can definitely see a use for security identifier tokens > in SE Postgres as well. Ideally these tokens would be 32 bit uints as > opposed to shorter string aliases. If you need something persistent you can't use what the kernel would provide, and if you don't you can make it up on the fly. The binder case is different (and evil) because the binder driver is letting user space make decisions on behalf of the kernel. > > --Mike > >> -- >> paul moore >> www.paul-moore.com >> >> ___ >> Selinux mailing list >> seli...@tycho.nsa.gov >> To unsubscribe, send email to selinux-le...@tycho.nsa.gov. >> To get help, send an email containing "help" to >> selinux-requ...@tycho.nsa.gov. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exposing secid to secctx mapping to user-space
> Subject: Re: Exposing secid to secctx mapping to user-space > > On 12/13/2015 2:06 PM, Paul Moore wrote: > > On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: > >> Perhaps we could provide a new fixed-size tokenized version of the > >> security context string for export to userspace that could be > >> embedded in the binder transaction structure? This could avoid both > >> the limitations of the current secid (e.g. limited to 32 bits, no > >> stackability) and the overhead of copying context strings on every IPC. > > On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: > >> How about this: Provide an alias mechanism for secctx. There would > >> then be a secid (32bits) a secctx (arbitrary text string) and a > >> secalias which could be a limited string of some length. You could > >> use the alias in place of the secctx anywhere you liked. > > My initial reaction to the secalias idea isn't overly positive. It > > seems like a kludge with a lot of duplication, both in terms of code > > and concept, and a lot of risk for confusion both by users and policy > > writers. I think if we really wanted to limit the security label > > string format to a small size we should have done that from the start, it's > > too > late now. > > The alias would be a user space controlled mapping. The kernel code would only > be involved at the border. I would never expect policy to be written using > aliases. > As for being a kludge, yeah, there's some of that, but I think that's true > with the > secid, too. > > > Assuming we see some binder performance numbers, and the numbers are > > bad, I'm a little more open to doing something with the secid token. > > Up to this point we haven't made any guarantees about the token and we > > haven't exported it outside the kernel so there is some ability to change > > it to fit > our needs. > > Granted, this isn't perfect solution either, and perhaps ultimately we > > would need something else, but I think it is worth looking into this > > first before we introduce another string label. > > I agree with getting numbers before someone dashes off to make a premature > optimization that exposes secids. If the numbers are bad I would hope that the > developers would look at fixing binder rather than exposing (and forever > requiring) secids. > If I understand correctly, the goal here is to avoid the lookup from pid to context. If we somehow Had the context or a token to a context during the ipc transaction to userspace, we could just use that In computing the access decision. If that is correct, then since we have PID, why not just extend the SE Linux compute av decision interface to support passing of PID and then it can do the lookup in the Kernel? -- 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
> > > > If I understand correctly, the goal here is to avoid the lookup from > > pid to context. If we somehow Had the context or a token to a context > > during the ipc transaction to userspace, we could just use that In > > computing the access decision. If that is correct, then since we have > > PID, why not just extend the SE Linux compute av decision interface to > > support > passing of PID and then it can do the lookup in the Kernel? > > That's no less racy than getpidcon(). > I got a bounce from when I sent this from gmail, resending. True, but in this case the binder transaction would be dead... Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big. grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' { thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen} END { printf("average: %dn", totlen/NR); } ' The avg type length for domain types in external/sepolicy is 7. Add the full ctx: u:r:xxx:s0(cat) 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"? 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough? 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips. -- 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 Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: > Perhaps we could provide a new fixed-size tokenized version of the > security context string for export to userspace that could be embedded > in the binder transaction structure? This could avoid both the > limitations of the current secid (e.g. limited to 32 bits, no > stackability) and the overhead of copying context strings on every IPC. On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: > How about this: Provide an alias mechanism for secctx. There would then > be a secid (32bits) a secctx (arbitrary text string) and a secalias which > could be a limited string of some length. You could use the alias in place > of the secctx anywhere you liked. My initial reaction to the secalias idea isn't overly positive. It seems like a kludge with a lot of duplication, both in terms of code and concept, and a lot of risk for confusion both by users and policy writers. I think if we really wanted to limit the security label string format to a small size we should have done that from the start, it's too late now. Assuming we see some binder performance numbers, and the numbers are bad, I'm a little more open to doing something with the secid token. Up to this point we haven't made any guarantees about the token and we haven't exported it outside the kernel so there is some ability to change it to fit our needs. Granted, this isn't perfect solution either, and perhaps ultimately we would need something else, but I think it is worth looking into this first before we introduce another string label. -- 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: 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 Cashmanwrote: 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 Cashmanwrote: >>> Hello, >>> >>> I would like to write a patch that would expose, via selinuxfs, the >>> mapping between secids in the kernel and security contexts to >>> user-space, but before doing so wanted to get some feedback as to >>> whether or not such an endeavor could have any support upstream. The >>> direct motivation for this is the desire to communicate calling security >>> ids/contexts over binder IPC on android for use in a user-space object >>> manager. Passing the security ids themselves would be simpler and more >>> efficient in the critical kernel path, but they currently have no >>> user-space meaning. >> >> In general we try to avoid exposing the secid tokens outside the >> kernel, I view them as an implementation hack designed to make it >> easier to manage and operate on the security labels in the kernel. I >> suspect you will hear something very similar from Casey and the other >> Smack developers. Another consideration is the long standing LSM >> stacking effort, they have several good reasons for wanting to abolish >> the secid token, propagating it to userspace would make that all but >> impossible. >> >> While I'm sympathetic to your desire for less complexity and better >> performance in passing security labels, from a kernel perspective I >> think we lose too much in exporting the secid tokens outside the LSM. > > To clarify, security identifiers were by design provided in the Flask > architecture and SELinux as lightweight, non-persistent handles to security > contexts, and exposed to userspace by the original SELinux API (pre-2.6, of > course). They were only removed when we transitioned to using extended > attributes and the xattr API for file security labels, and we made all of the > other APIs consistent as passing context strings seemed acceptable for proc > and selinuxfs as well. There was some thought to turning SIDs into proper > reference-counted objects or even wrapping them with descriptors so that > their lifecycles could be fully managed by the kernel, but that never > happened. > > Passing a security context string on every binder IPC may be too costly from > a performance point of view (numbers would be helpful here). I think this > situation differs from that of stream sockets (i.e. getsockopt SO_PEERSEC), > since they are looking at enabling passing of sender security label for every > binder IPC (not just specific applications) and since binder IPC is quite > different from stream socket IPC in its semantics and its performance. It seems to me that a better approach might be for the object manager to tell the binder driver about its security constraints and have the binder driver do the check in the kernel. I realize that could require additional LSM hooks (just like kdbus) but I think you may be looking at that anyway, unless you're convinced binder will only ever work with SELinux. > > Perhaps we could provide a new fixed-size tokenized version of the security > context string for export to userspace that could be embedded in the binder > transaction structure? This could avoid both the limitations of the current > secid (e.g. limited to 32 bits, no stackability) and the overhead of copying > context strings on every IPC. How about this: Provide an alias mechanism for secctx. There would then be a secid (32bits) a secctx (arbitrary text string) and a secalias which could be a limited string of some length. You could use the alias in place of the secctx anywhere you liked. You would always use the secalais in binder communications. The advantage is that the kernel would know that "#fish" was an alias for "Raygun_t:s27", just like the object manager. The other, longer term, advantage is that when (if?) we get to extreme module stacking we'll have a mechanism for dealing with a secctx like
Re: Exposing secid to secctx mapping to user-space
On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashmanwrote: > 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: 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 <dcash...@android.com> > Cc: seli...@tycho.nsa.gov; Stephen Smalley <s...@tycho.nsa.gov>; Eric Paris > <epa...@parisplace.org>; James Morris <james.l.mor...@oracle.com>; > 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 <dcash...@android.com> > 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�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf