Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: matchpathcon regcomp return code Date: Wed, 05 Oct 2005 16:14:13 +1000
Well, first message here (yeah). I have a double problem with restorecon crashing with a segfault.
Some background of the situation:
so basically, I changed the src/policy/file_contexts/types.fc and added '/var/lib/svn/lost\+found(/.*)? system_u:object_r:lost_found_t' to keep my lost+found dir secured. and changed my apache.fc file to add /var/lib/svn(/.*) to another type accessible by apache (let's say system_u:object_r:httpd_sys_content_t but could be anything else...) Anyway, This configuration will not work as expected since the apache.fc file is concatened after the types.fc, the lost+found will get the httpd_sys_content_t type.... So I tried to use a bit of regex and set up a look ahead assertion to avoid the lost+found and use the following regex (tested with perl happily): /var/lib/svn(?!(/.*)?/lost\\+found)(/.*)? Now the problem is restorecon is crashing (segfault in matchpathcon) About the crashing, it seems that the error code check of regcomp in matchpathcon.c is wrong (see attached patch from CVS HEAD). The second question is actually, is lookaround supported at all in posix regex ?
Cheers.
-- Johan Fischer Capital Markets CRC Limited Level 2, 9 Castlereagh Street, Sydney NSW 2000 Tel: +61 2 9233 7999 Direct: +61 2 9236 9150 Fax: +61 2 9236 9177 http://www.cmcrc.com Capital Markets CRC Ltd (CMCRC) - Confidential Communication The information contained in this e-mail is confidential. It is intended solely for the addressee. If you receive this e-mail by mistake please promptly inform us by reply e-mail and then delete the e-mail and destroy any printed copy. You must not disclose or use in any way the information in the e-mail. There is no warranty that this e-mail is error or virus free. It may be a private communication, and if so, does not represent the views of the CMCRC and its associates. If it is a private communication, care should be taken in opening it to ensure that undue offence is not given.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: matchpathcon regcomp return code Date: Wed, 05 Oct 2005 09:19:39 -0400
Yes, file contexts ordering/precedence is a known problem. It is exacerbated by the new policy module support, and Tresys has introduced a sorting algorithm for their reference policy (http://serefpolicy.sf.net) based on fixed string vs. regex (already done by matchpathcon), stem length, string length, and presence of the file type specifier. Possibly we should incorporate that sort into matchpathcon. Chris, is there a reason you kept it as a separate helper specific to reference policy versus submitting it as a patch to matchpathcon itself? I know that you mentioned that it does alter the order in some cases from what we have now, but I think we agreed that we can address those cases as needed.
> So I tried to use a bit of regex and set up a look ahead assertion to Ah, thanks for the bug fix. Should likely also call regerror there and report that error string.
> The second question is actually, is lookaround supported at all in posix I don't know offhand, but if regcomp rejects it, then I suspect not. Possibly we could convert it over to using pcre. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: matchpathcon regcomp return code Date: Wed, 05 Oct 2005 10:29:26 -0400
We kept it separate because we were still working with the algorithm. More importantly, we don't want to affect the example policy, since it altered the order on at least one occasion, as discussed before. If you don't have a problem with this, we can certainly work on a patch for matchpathcon. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: matchpathcon regcomp return code Date: Wed, 05 Oct 2005 10:34:57 -0400
Yes, I think it would be preferable to have it directly in matchpathcon, and we can add further pathname regexes as needed to fix any undesired changes in the actual labeling. I don't know if you've done anything further with respect to the idea floated earlier about (optional) explicit precedence/order specifiers in file contexts, but we might want to introduce those at the same time. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: matchpathcon regcomp return code Date: Thu, 06 Oct 2005 13:38:50 -0400
We haven't added any precedence/order specifiers in the file contexts, since, the previous problem I mentioned was fixed by adding another more specific regex. If we do want to add the optional specifiers, the question becomes how we want to use it for comparison? Should it be used as the last comparison, like a tie-breaker, or as the first comparison, which would group regexes of the same priority? Also, what happens if one regex has a precedence and the other doesn't? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: matchpathcon regcomp return code Date: Thu, 06 Oct 2005 14:42:24 -0400
Ok, let's defer that change until later and just focus on merging your existing sort algorithm into matchpathcon_init. BTW, is your sort stable? That was a problem we used to have when using qsort there; the ordering of "equal" members in the array was not stable. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: matchpathcon regcomp return code Date: Thu, 06 Oct 2005 17:28:57 -0400
Ok, we'll start working on a patch for matchpathcon_init. We do use a stable sort (mergesort). -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Johan Fischer <jfischer_at_cmcrc.com> subject: Re: matchpathcon regcomp return code Date: Fri, 07 Oct 2005 12:01:59 +1000
What happens if you have a sort of headers .fc file for suggested replaceable types (like the / and subtree context) and a trailer .fc to override important context in any case ( the lost+context and subdir) ? Christopher J. PeBenito wrote:
>On Wed, 2005-10-05 at 10:34 -0400, Stephen Smalley wrote: -- Johan Fischer Capital Markets CRC Limited Level 2, 9 Castlereagh Street, Sydney NSW 2000 Tel: +61 2 9233 7999 Direct: +61 2 9236 9150 Fax: +61 2 9236 9177 http://www.cmcrc.com Capital Markets CRC Ltd (CMCRC) - Confidential Communication The information contained in this e-mail is confidential. It is intended solely for the addressee. If you receive this e-mail by mistake please promptly inform us by reply e-mail and then delete the e-mail and destroy any printed copy. You must not disclose or use in any way the information in the e-mail. There is no warranty that this e-mail is error or virus free. It may be a private communication, and if so, does not represent the views of the CMCRC and its associates. If it is a private communication, care should be taken in opening it to ensure that undue offence is not given. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: matchpathcon regcomp return code Date: Wed, 05 Oct 2005 12:17:15 -0400
I merged the patch below into libselinux 1.27.4. Includes your change plus use of regerror. With regard to the original problem, I think you just have to put both pathname regexes (the top-level /var/lib/svn one and the lost+found one) into apache.fc with the desired ordering explicit for now. We are looking into ways to address the general ordering issues in the future, including the sort algorithm mentioned earlier and an optional explicit ordering/predecence value field in the .fc entries. -- Stephen Smalley National Security AgencyFrom: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: matchpathcon regcomp return code Date: Mon, 10 Oct 2005 10:03:04 -0400
We were thinking about this a little more. Since sorting the file contexts is a relatively expensive operation, wouldn't it be better to just sort the file contexts once on install, rather than redoing it on every matchpathcon/setfiles/restorecon? Source policies that need more than the simple sort already done in matchpathcon_init can sort the file contexts on install, and the loadable modules infrastructure can sort for loadable modules. This has the advantage of not disturbing the example policy. Then the sorting would be added to libselinux as a library function, along with a util program for source policies to use for sorting. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: matchpathcon regcomp return code Date: Tue, 11 Oct 2005 08:07:05 -0400
I'm uneasy about leaving this to policy (re)generation; I would prefer that matchpathcon apply a well-defined ordering/precedence to file contexts (including file_contexts.homedirs and file_contexts.local, which at least presently can be changed without going through a policy build). Note that this only occurs during initialization (matchpathcon_init), not on every matchpathcon call by an application. I'm also unclear on whether the overhead from sorting the entries in memory is actually substantial compared to the rest of what matchpathcon/matchpathcon_init does already. The regex compilation and matching seems more costly. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |