From: jwcart2 <jwcart2@tycho.nsa.gov>
To: Dominick Grift <dominick.grift@defensec.nl>, selinux@vger.kernel.org
Subject: Re: [Non-DoD Source] Re: any reason why a class mapping is not able to solve permissionx?
Date: Thu, 23 Jan 2020 15:41:30 -0500 [thread overview]
Message-ID: <b1a48f5e-6b11-ea21-a90a-5ae5fd8a12c5@tycho.nsa.gov> (raw)
In-Reply-To: <904dcd8e-9b0b-b444-4931-4dc165e4fb1f@tycho.nsa.gov>
On 1/21/20 11:26 AM, jwcart2 wrote:
> On 1/17/20 1:24 PM, Dominick Grift wrote:
>> On Fri, Jan 17, 2020 at 06:34:48PM +0100, Dominick Grift wrote:
>>> For example this:
>>>
>>> (permissionx alg_socket_ioctl_except_SIOCGIFHWADDR (ioctl alg_socket (and
>>> (all) (not (0x8927)))))
>>> (classmap all_sockets (ioctl_except_SIOCGIFHWADDR))
>>> (classmapping all_sockets ioctl_except_SIOCGIFHWADDR
>>> alg_socket_ioctl_except_SIOCGIFHWADDR)
>>>
>>> (allowx a self (all_sockets (ioctl_except_SIOCGIFHWADDR)))
>>>
>>> Say's:
>>>
>>> <snip>
>>> Building AST from Parse Tree
>>> Destroying Parse Tree
>>> Resolving AST
>>> Failed to resolve classmapping statement at policy/base/class_maps.cil:994
>>> Problem at policy/base/class_maps.cil:994
>>> Pass 14 of resolution failed
>>> Failed to resolve ast
>>> Failed to compile cildb: -2
>>> make: *** [Makefile:30: policy.32] Error 254
>>>
>>> Am i doing something wrong or is this unsupported?
>>
>> Are we supposed to be able to use allowx rules in macros?
>>
>
> Yes, allowx rules can be used in macros.
>
>> This works when the tunable is set false:
>>
>> (tunable no_mac_addr true)
>>
>> (block bla1
>> (blockinherit system_agent_template)
>>
>> (macro stuff ((type ARG1))
>> (tunableif no_mac_addr
>> (true
>> (allow ARG1 self
>> create_except_ioctl_tcp_stream_socket_perms)
>> (allowx ARG1 self tcp_socket_ioctl_except_SIOCGIFHWADDR))
>> (false
>> (allow ARG1 self create_tcp_stream_socket_perms)))))
>>
>> (block blah2
>> (blockinherit system_agent_template)
>>
>> (call bla1.stuff (subj)))
>>
>> But when the tunable is set true:
>> <snip>
>> Building AST from Parse Tree
>> Destroying Parse Tree
>> Resolving AST
>> make: *** [Makefile:30: policy.32] Segmentation fault (core dumped)
>>
>
> Still trying to figure out the exact issue, but it is the use of the named
> permissionx that is causing the seg fault.
>
There was an error in the code to copy a permissionx. I sent a patch to the list
to fix this issue.
Jim
> Jim
>
--
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency
next prev parent reply other threads:[~2020-01-23 20:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-17 17:34 any reason why a class mapping is not able to solve permissionx? Dominick Grift
2020-01-17 18:24 ` Dominick Grift
2020-01-17 18:36 ` [Non-DoD Source] " jwcart2
2020-01-21 16:26 ` jwcart2
2020-01-23 20:41 ` jwcart2 [this message]
2020-01-23 21:15 ` Dominick Grift
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1a48f5e-6b11-ea21-a90a-5ae5fd8a12c5@tycho.nsa.gov \
--to=jwcart2@tycho.nsa.gov \
--cc=dominick.grift@defensec.nl \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).