Announcing SPAN: SELinux Policy Analysis Notebook

Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]

I’d like to announce SPAN - SELinux Policy Analysis Notebook (https://github.com/QuarkSecurity/SPAN/ <https://github.com/QuarkSecurity/SPAN/>). This is a Jupyter notebook based environment for SELinux policy analysis that let’s you mix queries, Python code, and Markdown formatted notes into an executable document. It’s an extension of SETools 4.

Using SPAN within Jupyter notebook is an amazingly productive way to do policy analysis. I really think that this is the most productive environment that I’ve seen for real policy analysis (and I’ve been working on SELinux policy analysis and tools for almost 15 years). The ability to quickly create custom tools to answer hard questions combined inline with well-formatted documentation makes a huge difference.

SPAN has been used so far to analyze 3 large, complex, custom systems with very large policies (hundreds of custom domains). The analysis was of much better quality and it took much less time because of SPAN.

If you just want to see what this looks like, you can see an example online (though the code is not executable):

https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb# <https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb#>

If you’ve not seen Jupyter notebooks, they are a very popular tool for data science. Jupyter notebooks are an interactive environment that let you write text (in Markdown) and code together. You can get a feel for what's possible in this awesome notebook on Regex Golf from XKCD: http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb <http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb>. There is also the more official (and boring) introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/ <https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/>.

SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Brandon Whalen from Quark Security. And, of course, this is built on SETools 4 which is maintained by Chris PeBinito.

Thanks - Karl

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

On Fri, May 05, 2017 at 02:27:05PM -0400, Karl MacMillan wrote:
> I’d like to announce SPAN - SELinux Policy Analysis Notebook (https://github.com/QuarkSecurity/SPAN/ <https://github.com/QuarkSecurity/SPAN/>). This is a Jupyter notebook based environment for SELinux policy analysis that let’s you mix queries, Python code, and Markdown formatted notes into an executable document. It’s an extension of SETools 4.
> 
> Using SPAN within Jupyter notebook is an amazingly productive way to do policy analysis. I really think that this is the most productive environment that I’ve seen for real policy analysis (and I’ve been working on SELinux policy analysis and tools for almost 15 years). The ability to quickly create custom tools to answer hard questions combined inline with well-formatted documentation makes a huge difference.
> 
> SPAN has been used so far to analyze 3 large, complex, custom systems with very large policies (hundreds of custom domains). The analysis was of much better quality and it took much less time because of SPAN.
> 
> If you just want to see what this looks like, you can see an example online (though the code is not executable):
> 
> https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb# <https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb#>
> 
> If you’ve not seen Jupyter notebooks, they are a very popular tool for data science. Jupyter notebooks are an interactive environment that let you write text (in Markdown) and code together. You can get a feel for what's possible in this awesome notebook on Regex Golf from XKCD: http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb <http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb>. There is also the more official (and boring) introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/ <https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/>.
> 
> SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Brandon Whalen from Quark Security. And, of course, this is built on SETools 4 which is maintained by Chris PeBinito.
> 
> Thanks - Karl

Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:

Fedora 26 (alpha):
sudo dnf install setools setools-console libselinux-python3 pandoc which
git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
cd examples && jupyter-notebook

As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 

All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]

On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:
> On Fri, May 05, 2017 at 02:27:05PM -0400, Karl MacMillan wrote:
> > I’d like to announce SPAN - SELinux Policy Analysis Notebook (https://github.com/QuarkSecurity/SPAN/ <https://github.com/QuarkSecurity/SPAN/>). This is a Jupyter notebook based environment for SELinux policy analysis that let’s you mix queries, Python code, and Markdown formatted notes into an executable document. It’s an extension of SETools 4.
> > 
> > Using SPAN within Jupyter notebook is an amazingly productive way to do policy analysis. I really think that this is the most productive environment that I’ve seen for real policy analysis (and I’ve been working on SELinux policy analysis and tools for almost 15 years). The ability to quickly create custom tools to answer hard questions combined inline with well-formatted documentation makes a huge difference.
> > 
> > SPAN has been used so far to analyze 3 large, complex, custom systems with very large policies (hundreds of custom domains). The analysis was of much better quality and it took much less time because of SPAN.
> > 
> > If you just want to see what this looks like, you can see an example online (though the code is not executable):
> > 
> > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb# <https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb#>
> > 
> > If you’ve not seen Jupyter notebooks, they are a very popular tool for data science. Jupyter notebooks are an interactive environment that let you write text (in Markdown) and code together. You can get a feel for what's possible in this awesome notebook on Regex Golf from XKCD: http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb <http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb>. There is also the more official (and boring) introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/ <https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/>.
> > 
> > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Brandon Whalen from Quark Security. And, of course, this is built on SETools 4 which is maintained by Chris PeBinito.
> > 
> > Thanks - Karl
> 
> Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:
> 
> Fedora 26 (alpha):
> sudo dnf install setools setools-console libselinux-python3 pandoc which
> git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
> cd examples && jupyter-notebook
> 
> As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 
> 
> All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"

I dont know exactly what the issue is but after installing the following from the fedora repository i seem to have it working:

python3-pypandoc
python3-pandocfilters
python3-sh

So i suspect the "from sh import pandoc" was the issue because sh was not in the python_requirements.txt, but even after adding it there it still did not work

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]

On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:
> > On Fri, May 05, 2017 at 02:27:05PM -0400, Karl MacMillan wrote:
> > > I’d like to announce SPAN - SELinux Policy Analysis Notebook (https://github.com/QuarkSecurity/SPAN/ <https://github.com/QuarkSecurity/SPAN/>). This is a Jupyter notebook based environment for SELinux policy analysis that let’s you mix queries, Python code, and Markdown formatted notes into an executable document. It’s an extension of SETools 4.
> > > 
> > > Using SPAN within Jupyter notebook is an amazingly productive way to do policy analysis. I really think that this is the most productive environment that I’ve seen for real policy analysis (and I’ve been working on SELinux policy analysis and tools for almost 15 years). The ability to quickly create custom tools to answer hard questions combined inline with well-formatted documentation makes a huge difference.
> > > 
> > > SPAN has been used so far to analyze 3 large, complex, custom systems with very large policies (hundreds of custom domains). The analysis was of much better quality and it took much less time because of SPAN.
> > > 
> > > If you just want to see what this looks like, you can see an example online (though the code is not executable):
> > > 
> > > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb# <https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb#>
> > > 
> > > If you’ve not seen Jupyter notebooks, they are a very popular tool for data science. Jupyter notebooks are an interactive environment that let you write text (in Markdown) and code together. You can get a feel for what's possible in this awesome notebook on Regex Golf from XKCD: http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb <http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb>. There is also the more official (and boring) introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/ <https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/>.
> > > 
> > > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Brandon Whalen from Quark Security. And, of course, this is built on SETools 4 which is maintained by Chris PeBinito.
> > > 
> > > Thanks - Karl
> > 
> > Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:
> > 
> > Fedora 26 (alpha):
> > sudo dnf install setools setools-console libselinux-python3 pandoc which
> > git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
> > cd examples && jupyter-notebook
> > 
> > As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 
> > 
> > All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"
> 
> I dont know exactly what the issue is but after installing the following from the fedora repository i seem to have it working:
> 
> python3-pypandoc
> python3-pandocfilters
> python3-sh
> 
> So i suspect the "from sh import pandoc" was the issue because sh was not in the python_requirements.txt, but even after adding it there it still did not work

The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.

> 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]

On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote:
> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
> > On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:
> > > On Fri, May 05, 2017 at 02:27:05PM -0400, Karl MacMillan wrote:
> > > > I’d like to announce SPAN - SELinux Policy Analysis Notebook (https://github.com/QuarkSecurity/SPAN/ <https://github.com/QuarkSecurity/SPAN/>). This is a Jupyter notebook based environment for SELinux policy analysis that let’s you mix queries, Python code, and Markdown formatted notes into an executable document. It’s an extension of SETools 4.
> > > > 
> > > > Using SPAN within Jupyter notebook is an amazingly productive way to do policy analysis. I really think that this is the most productive environment that I’ve seen for real policy analysis (and I’ve been working on SELinux policy analysis and tools for almost 15 years). The ability to quickly create custom tools to answer hard questions combined inline with well-formatted documentation makes a huge difference.
> > > > 
> > > > SPAN has been used so far to analyze 3 large, complex, custom systems with very large policies (hundreds of custom domains). The analysis was of much better quality and it took much less time because of SPAN.
> > > > 
> > > > If you just want to see what this looks like, you can see an example online (though the code is not executable):
> > > > 
> > > > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb# <https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/examples/Span%20Example.ipynb#>
> > > > 
> > > > If you’ve not seen Jupyter notebooks, they are a very popular tool for data science. Jupyter notebooks are an interactive environment that let you write text (in Markdown) and code together. You can get a feel for what's possible in this awesome notebook on Regex Golf from XKCD: http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb <http://nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb>. There is also the more official (and boring) introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/ <https://jupyter-notebook-beginner-guide.readthedocs.io/en/latest/>.
> > > > 
> > > > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Brandon Whalen from Quark Security. And, of course, this is built on SETools 4 which is maintained by Chris PeBinito.
> > > > 
> > > > Thanks - Karl
> > > 
> > > Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:
> > > 
> > > Fedora 26 (alpha):
> > > sudo dnf install setools setools-console libselinux-python3 pandoc which
> > > git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
> > > cd examples && jupyter-notebook
> > > 
> > > As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 
> > > 
> > > All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"
> > 
> > I dont know exactly what the issue is but after installing the following from the fedora repository i seem to have it working:
> > 
> > python3-pypandoc
> > python3-pandocfilters
> > python3-sh
> > 
> > So i suspect the "from sh import pandoc" was the issue because sh was not in the python_requirements.txt, but even after adding it there it still did not work
> 
> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.


Turns out that Fedora provides all the dependencies (some just have different names)

I have created a Fedora SPAN.spec:

https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec


> 
> > 
> > > 
> > > -- 
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > Dominick Grift
> > 
> > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]


> On May 7, 2017, at 5:39 AM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote:
>> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
>>> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:

[snip]

>>>> 
>>>> Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:
>>>> 
>>>> Fedora 26 (alpha):
>>>> sudo dnf install setools setools-console libselinux-python3 pandoc which
>>>> git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
>>>> cd examples && jupyter-notebook
>>>> 
>>>> As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 
>>>> 
>>>> All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"
>>> 
>>> I dont know exactly what the issue is but after installing the following from the fedora repository i seem to have it working:
>>> 
>>> python3-pypandoc
>>> python3-pandocfilters
>>> python3-sh
>>> 
>>> So i suspect the "from sh import pandoc" was the issue because sh was not in the python_requirements.txt, but even after adding it there it still did not work
>> 

I updated python_requirements.txt to include sh - thanks for that.

>> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> 
> 
> Turns out that Fedora provides all the dependencies (some just have different names)
> 
> I have created a Fedora SPAN.spec:
> 
> https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec <https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec>
> 
> 

Thanks for making the Fedora SPEC. 

I know it’s a topic of great debate, but there are some nice things about just sticking with the Python tools for dependency management for upstream. Mainly because it’s portable and helps get the latest versions (which is nice for fast moving projects like Jupyter notebook and Pandas).

Karl


>> 
>>> 
>>>> 
>>>> -- 
>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>>>> Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>>> Dominick Grift
>> 
>> 
>> 
>> -- 
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>> Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift


[-- Attachment #2: Type: text/html, Size: 13930 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4200 bytes --]

On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote:
> 
> > On May 7, 2017, at 5:39 AM, Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote:
> >> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
> >>> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:
> 
> [snip]
> 
> >>>> 
> >>>> Nice! Unfornately i could not, which my limited capacity, get it to work. Here is what i tried:
> >>>> 
> >>>> Fedora 26 (alpha):
> >>>> sudo dnf install setools setools-console libselinux-python3 pandoc which
> >>>> git clone https://github.com/quarcksecurity/span && cd span && pip3 install . --user
> >>>> cd examples && jupyter-notebook
> >>>> 
> >>>> As soon as i try to run any "cell" or do "restart kernel and run all cells" it throws stack traces about "ModuleNotFoundError" (import span as se" and "from sh import pandoc" 
> >>>> 
> >>>> All the stuff seems to be installed properly in ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the proper paths suchs as for example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py in <module> ()"
> >>> 
> >>> I dont know exactly what the issue is but after installing the following from the fedora repository i seem to have it working:
> >>> 
> >>> python3-pypandoc
> >>> python3-pandocfilters
> >>> python3-sh
> >>> 
> >>> So i suspect the "from sh import pandoc" was the issue because sh was not in the python_requirements.txt, but even after adding it there it still did not work
> >> 
> 
> I updated python_requirements.txt to include sh - thanks for that.
> 
> >> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > 
> > 
> > Turns out that Fedora provides all the dependencies (some just have different names)
> > 
> > I have created a Fedora SPAN.spec:
> > 
> > https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec <https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec>
> > 
> > 
> 
> Thanks for making the Fedora SPEC. 
> 
> I know it’s a topic of great debate, but there are some nice things about just sticking with the Python tools for dependency management for upstream. Mainly because it’s portable and helps get the latest versions (which is nice for fast moving projects like Jupyter notebook and Pandas).

Yes it is pretty cool (pip) and this event actually prompted me to make pip work in my environment. However for me in this case it is really not an option. Its nice for simple python modules but python programs such as notebook need permissions that i do not associate will login users shells, and i dont support confining applications installed to $HOME. notebook needs permissions like execmem, needs network connectivity and a few other things that i do not allow my user login shells. So I have to make this work system-wide and I wanted the benefit of being able to manage/keep track off what i install system-wide

> 
> Karl
> 
> 
> >> 
> >>> 
> >>>> 
> >>>> -- 
> >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> >>>> Dominick Grift
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> >>> Dominick Grift
> >> 
> >> 
> >> 
> >> -- 
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> > 
> > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > Dominick Grift
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]


> On May 8, 2017, at 3:32 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote:
>>> 
>> 
>> Thanks for making the Fedora SPEC. 
>> 
>> I know it’s a topic of great debate, but there are some nice things about just sticking with the Python tools for dependency management for upstream. Mainly because it’s portable and helps get the latest versions (which is nice for fast moving projects like Jupyter notebook and Pandas).
> 
> Yes it is pretty cool (pip) and this event actually prompted me to make pip work in my environment. However for me in this case it is really not an option. Its nice for simple python modules but python programs such as notebook need permissions that i do not associate will login users shells, and i dont support confining applications installed to $HOME. notebook needs permissions like execmem, needs network connectivity and a few other things that i do not allow my user login shells. So I have to make this work system-wide and I wanted the benefit of being able to manage/keep track off what i install system-wide
> 

Interesting. I’ll just note that it’s perfectly possible to run Jupyter Notebook as a server and connect to it via a web-browser. So it would be simple to run Jupyter in a container or VM, which might make containing it easier. Personally, I just run this on a development system that’s not so locked down.

Karl

>> 
>> Karl
>> 
>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>>>>>> Dominick Grift
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>>>>> Dominick Grift
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>>>> Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>>> Dominick Grift
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift


[-- Attachment #2: Type: text/html, Size: 9578 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Joshua Brindle]

Dominick Grift wrote:
<snip>

> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
>

Of course, it is an analysis of a refpolicy-based policy. If you want to 
analyze a different policy (e.g., Android or home-rolled) you will have 
to change out all of the type sets, etc.

You can't make a magic generic analysis script without knowing how key 
parts of the system work and what types are associated with those 
components.

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> <snip>
> 
> > The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > 
> 
> Of course, it is an analysis of a refpolicy-based policy. If you want to
> analyze a different policy (e.g., Android or home-rolled) you will have to
> change out all of the type sets, etc.
> 
> You can't make a magic generic analysis script without knowing how key parts
> of the system work and what types are associated with those components.

What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.

Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.

Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?

> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Joshua Brindle]

Dominick Grift wrote:
> On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
>> Dominick Grift wrote:
>> <snip>
>>
>>> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
>>>
>> Of course, it is an analysis of a refpolicy-based policy. If you want to
>> analyze a different policy (e.g., Android or home-rolled) you will have to
>> change out all of the type sets, etc.
>>
>> You can't make a magic generic analysis script without knowing how key parts
>> of the system work and what types are associated with those components.
>
> What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
>

you mean the example trusted types? I'm not sure I understand your concern.

> Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
>

It is python, you can do anything you want. The example notebook is a 
starting point, anyone doing an analysis would probably make major 
changes for their analysis, which is the point. You modify the notebook 
to build a usable analysis between the starting policy and the policy 
you are analyzing.

I've thought about trying this on an Android policy but haven't made it 
a priority.

> Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> > > Dominick Grift wrote:
> > > <snip>
> > > 
> > > > The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > > > 
> > > Of course, it is an analysis of a refpolicy-based policy. If you want to
> > > analyze a different policy (e.g., Android or home-rolled) you will have to
> > > change out all of the type sets, etc.
> > > 
> > > You can't make a magic generic analysis script without knowing how key parts
> > > of the system work and what types are associated with those components.
> > 
> > What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
> > 
> 
> you mean the example trusted types? I'm not sure I understand your concern.

Yes my mistake, that array is just an example? Anyhow it distracted me. The array isnt so much an issue. The bigger issue is that i cannot easily override the ps.policy_config_source file suffixes and paths from the notebook (am i over looking this?)

But yes, i think these issues will eventually be addressed automatically.

It works pretty well for me now.

> 
> > Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
> > 
> 
> It is python, you can do anything you want. The example notebook
> is a starting point, anyone doing an analysis would probably make
> major changes for their analysis, which is the point. You modify
> the notebook to build a usable analysis between the starting
> policy and the policy you are analyzing.
> 
> I've thought about trying this on an Android policy but haven't
> made it a priority.
> 

Python is not really my thing so i will have to get used to it and explore my options

Its a cool module, has a few rough edges (but thats to be expected from v0.0.0)

> > Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]


> On May 7, 2017, at 3:53 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> 
> Python is not really my thing so i will have to get used to it and explore my options
> 
> Its a cool module, has a few rough edges (but thats to be expected from v0.0.0)
> 

So far I’ve seen your concerns over installation and reference policy assumptions. Any other “rough edges” that you’ve seen?

Thanks - Karl

>>> Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
>> 
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift


[-- Attachment #2: Type: text/html, Size: 6534 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> > > Dominick Grift wrote:
> > > <snip>
> > > 
> > > > The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > > > 
> > > Of course, it is an analysis of a refpolicy-based policy. If you want to
> > > analyze a different policy (e.g., Android or home-rolled) you will have to
> > > change out all of the type sets, etc.
> > > 
> > > You can't make a magic generic analysis script without knowing how key parts
> > > of the system work and what types are associated with those components.
> > 
> > What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
> > 
> 
> you mean the example trusted types? I'm not sure I understand your concern.
> 
> > Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
> > 
> 
> It is python, you can do anything you want. The example notebook is a
> starting point, anyone doing an analysis would probably make major changes
> for their analysis, which is the point. You modify the notebook to build a
> usable analysis between the starting policy and the policy you are
> analyzing.
> 
> I've thought about trying this on an Android policy but haven't made it a
> priority.
> 
> > Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
> 
> 

ahh.. sorry. I just noticed that it can be overriden:

p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")

so i suppose i should be able to add that file to the notebook dir and specify my own paths.

although that still doesnt deal with any file suffixes? (.cil)

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]

On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> > Dominick Grift wrote:
> > > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> > > > Dominick Grift wrote:
> > > > <snip>
> > > > 
> > > > > The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > > > > 
> > > > Of course, it is an analysis of a refpolicy-based policy. If you want to
> > > > analyze a different policy (e.g., Android or home-rolled) you will have to
> > > > change out all of the type sets, etc.
> > > > 
> > > > You can't make a magic generic analysis script without knowing how key parts
> > > > of the system work and what types are associated with those components.
> > > 
> > > What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
> > > 
> > 
> > you mean the example trusted types? I'm not sure I understand your concern.
> > 
> > > Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
> > > 
> > 
> > It is python, you can do anything you want. The example notebook is a
> > starting point, anyone doing an analysis would probably make major changes
> > for their analysis, which is the point. You modify the notebook to build a
> > usable analysis between the starting policy and the policy you are
> > analyzing.
> > 
> > I've thought about trying this on an Android policy but haven't made it a
> > priority.
> > 
> > > Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
> > 
> > 
> 
> ahh.. sorry. I just noticed that it can be overriden:
> 
> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
> 
> so i suppose i should be able to add that file to the notebook dir and specify my own paths.
> 
> although that still doesnt deal with any file suffixes? (.cil)


take for example: https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331

"domain" is a reference policy type attribute

One should expand on the "policy_paths.config" concept and allow us, via configuration files, to override all the variables (attributes, suffixes, paths, identifiers, etc)

So that the variables can we adjusted without the need to reinstall/recompile a modified SPAN

Or just rename to RPAN (reference policy analysis notebook)

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 4893 bytes --]


> On May 8, 2017, at 5:32 AM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
>> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
>>> Dominick Grift wrote:
>>>> On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
>>>>> Dominick Grift wrote:
>>>>> <snip>
>>>>> 
>>>>>> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
>>>>>> 
>>>>> Of course, it is an analysis of a refpolicy-based policy. If you want to
>>>>> analyze a different policy (e.g., Android or home-rolled) you will have to
>>>>> change out all of the type sets, etc.
>>>>> 
>>>>> You can't make a magic generic analysis script without knowing how key parts
>>>>> of the system work and what types are associated with those components.
>>>> 
>>>> What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
>>>> 
>>> 
>>> you mean the example trusted types? I'm not sure I understand your concern.
>>> 
>>>> Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
>>>> 
>>> 
>>> It is python, you can do anything you want. The example notebook is a
>>> starting point, anyone doing an analysis would probably make major changes
>>> for their analysis, which is the point. You modify the notebook to build a
>>> usable analysis between the starting policy and the policy you are
>>> analyzing.
>>> 
>>> I've thought about trying this on an Android policy but haven't made it a
>>> priority.
>>> 
>>>> Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
>>> 
>>> 
>> 
>> ahh.. sorry. I just noticed that it can be overriden:
>> 
>> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
>> 
>> so i suppose i should be able to add that file to the notebook dir and specify my own paths.
>> 
>> although that still doesnt deal with any file suffixes? (.cil)
> 
> 
> take for example: https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331 <https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331>
> 
> "domain" is a reference policy type attribute
> 
> One should expand on the "policy_paths.config" concept and allow us, via configuration files, to override all the variables (attributes, suffixes, paths, identifiers, etc)
> 
> So that the variables can we adjusted without the need to reinstall/recompile a modified SPAN
> 
> Or just rename to RPAN (reference policy analysis notebook)

I think it’s best to think of these as having three basic layers:

1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.

2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.

3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.

So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.

Thanks - Karl

> 
>> 
>> -- 
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>> Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift


[-- Attachment #2: Type: text/html, Size: 16182 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5902 bytes --]

On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 5:32 AM, Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
> >> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> >>> Dominick Grift wrote:
> >>>> On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> >>>>> Dominick Grift wrote:
> >>>>> <snip>
> >>>>> 
> >>>>>> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> >>>>>> 
> >>>>> Of course, it is an analysis of a refpolicy-based policy. If you want to
> >>>>> analyze a different policy (e.g., Android or home-rolled) you will have to
> >>>>> change out all of the type sets, etc.
> >>>>> 
> >>>>> You can't make a magic generic analysis script without knowing how key parts
> >>>>> of the system work and what types are associated with those components.
> >>>> 
> >>>> What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
> >>>> 
> >>> 
> >>> you mean the example trusted types? I'm not sure I understand your concern.
> >>> 
> >>>> Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
> >>>> 
> >>> 
> >>> It is python, you can do anything you want. The example notebook is a
> >>> starting point, anyone doing an analysis would probably make major changes
> >>> for their analysis, which is the point. You modify the notebook to build a
> >>> usable analysis between the starting policy and the policy you are
> >>> analyzing.
> >>> 
> >>> I've thought about trying this on an Android policy but haven't made it a
> >>> priority.
> >>> 
> >>>> Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
> >>> 
> >>> 
> >> 
> >> ahh.. sorry. I just noticed that it can be overriden:
> >> 
> >> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
> >> 
> >> so i suppose i should be able to add that file to the notebook dir and specify my own paths.
> >> 
> >> although that still doesnt deal with any file suffixes? (.cil)
> > 
> > 
> > take for example: https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331 <https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331>
> > 
> > "domain" is a reference policy type attribute
> > 
> > One should expand on the "policy_paths.config" concept and allow us, via configuration files, to override all the variables (attributes, suffixes, paths, identifiers, etc)
> > 
> > So that the variables can we adjusted without the need to reinstall/recompile a modified SPAN
> > 
> > Or just rename to RPAN (reference policy analysis notebook)
> 
> I think it’s best to think of these as having three basic layers:
> 
> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> 
> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> 
> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> 
> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.

I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
Thank you for giving me your opinion. At least now I know where I stand. I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.

> 
> Thanks - Karl
> 
> > 
> >> 
> >> -- 
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> >> Dominick Grift
> > 
> > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > Dominick Grift
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]


> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
>> 
>>> 
>> 
>> I think it’s best to think of these as having three basic layers:
>> 
>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
>> 
>> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
>> 
>> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
>> 
>> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> 
> I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.

We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.

> Thank you for giving me your opinion. At least now I know where I stand.

Where you stand? I’m not certain what you mean and was not trying to say something about you personally.

I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).

And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?

> I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.

I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.

And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.

Thanks - Karl

> Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> 
>> 
>> Thanks - Karl
>> 
>>> 
>>>> 
>>>> -- 
>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>>>> Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>>> Dominick Grift
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift


[-- Attachment #2: Type: text/html, Size: 12802 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6864 bytes --]

On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> >> 
> >>> 
> >> 
> >> I think it’s best to think of these as having three basic layers:
> >> 
> >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> >> 
> >> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> >> 
> >> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> >> 
> >> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> > 
> > I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> 
> We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> 
> > Thank you for giving me your opinion. At least now I know where I stand.
> 
> Where you stand? I’m not certain what you mean and was not trying to say something about you personally.

I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)

> 
> I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> 
> And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?

Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is "subj.subj_type_attribute"

So if the configuration file would have something like:

# process_types = domain

Then i would be happy because then i could edit it like:

process_types = subj.subj_type_attribute

> 
> > I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> 
> I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.

Let me rephrase then: "not to the fullest extent"

But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach."

> 
> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.

I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:

ill point out some:

1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
2. return self.find_def("attribute " + name) # in CIL this is typeattribute
3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
4. 
return self.diff_relative("/policy/mls", other_source) # these should be customizable
return self.diff_relative("/policy/mcs", other_source) # these should be customizable
return self.diff_relative("/policy/constraints", other_source) # these should be customizable
5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = ... etc

> 
> Thanks - Karl
> 
> > Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> > 
> >> 
> >> Thanks - Karl
> >> 
> >>> 
> >>>> 
> >>>> -- 
> >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> >>>> Dominick Grift
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> >>> Dominick Grift
> >> 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > Dominick Grift
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 8737 bytes --]

On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > 
> > > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > 
> > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> > >> 
> > >>> 
> > >> 
> > >> I think it’s best to think of these as having three basic layers:
> > >> 
> > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> > >> 
> > >> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> > >> 
> > >> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> > >> 
> > >> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> > > 
> > > I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> > 
> > We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> > 
> > > Thank you for giving me your opinion. At least now I know where I stand.
> > 
> > Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> 
> I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> 
> > 
> > I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> > 
> > And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> 
> Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is "subj.subj_type_attribute"
> 
> So if the configuration file would have something like:
> 
> # process_types = domain
> 
> Then i would be happy because then i could edit it like:
> 
> process_types = subj.subj_type_attribute
> 
> > 
> > > I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> > 
> > I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> 
> Let me rephrase then: "not to the fullest extent"
> 
> But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach."
> 
> > 
> > And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> 
> I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> 
> ill point out some:
> 
> 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?

We should make this customizable something like: source_policy_suffix =

Because we would need to catch *.conf , *.te , *.cil and any future high level source policy files that leverage cil

> 2. return self.find_def("attribute " + name) # in CIL this is typeattribute

CIL is a native language so we use a statement for something then we need to make sure that also its CIL equivalent is caught

> 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file

We should make this customizable: file_contexts_suffix =
to catch *.fc as well as *.cil and any future high level file_context suffixes
When this suffix is used we should also alway take "file_contexts" into account as this is where to look in monolitic policy

> 4. 
> return self.diff_relative("/policy/mls", other_source) # these should be customizable

mls_constraints =

> return self.diff_relative("/policy/mcs", other_source) # these should be customizable

mcs_constraints =

> return self.diff_relative("/policy/constraints", other_source) # these should be customizable

constraints =

or maybe dont even differentiate between the various different constraints and just pile them all together in:

constraints = [ "", "", "", ... ]

This is because there may be other constraints (for example i have role-base access control seperation constraints)

> 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = ... etc

I do not consider Linux access vectors to be customizable, unlike types ,attributes, booleans, tunables etc)

So one does not have to worry about the hard coding of classes and permission, However i would probably still try to find a way
make that more easily customizable. Because new permissions get added to existing classes and if you have you access vector declarations in a single place then that is easier to maintain then when you have to add then in code scathered accross the project

> 
> > 
> > Thanks - Karl
> > 
> > > Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> > > 
> > >> 
> > >> Thanks - Karl
> > >> 
> > >>> 
> > >>>> 
> > >>>> -- 
> > >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > >>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > >>>> Dominick Grift
> > >>> 
> > >>> 
> > >>> 
> > >>> -- 
> > >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > >>> Dominick Grift
> > >> 
> > > 
> > > -- 
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > > Dominick Grift
> > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 9716 bytes --]

On Mon, May 08, 2017 at 11:47:14PM +0200, Dominick Grift wrote:
> On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
> > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > > 
> > > > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > > 
> > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> > > >> 
> > > >>> 
> > > >> 
> > > >> I think it’s best to think of these as having three basic layers:
> > > >> 
> > > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> > > >> 
> > > >> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> > > >> 
> > > >> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> > > >> 
> > > >> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> > > > 
> > > > I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> > > 
> > > We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> > > 
> > > > Thank you for giving me your opinion. At least now I know where I stand.
> > > 
> > > Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> > 
> > I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> > The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> > What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> > 
> > > 
> > > I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> > > 
> > > And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> > 
> > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is "subj.subj_type_attribute"
> > 
> > So if the configuration file would have something like:
> > 
> > # process_types = domain
> > 
> > Then i would be happy because then i could edit it like:
> > 
> > process_types = subj.subj_type_attribute
> > 
> > > 
> > > > I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> > > 
> > > I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> > 
> > Let me rephrase then: "not to the fullest extent"
> > 
> > But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach."
> > 
> > > 
> > > And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> > 
> > I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> > 
> > ill point out some:
> > 
> > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> 
> We should make this customizable something like: source_policy_suffix =
> 
> Because we would need to catch *.conf , *.te , *.cil and any future high level source policy files that leverage cil
> 
> > 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
> 
> CIL is a native language so we use a statement for something then we need to make sure that also its CIL equivalent is caught
> 
> > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
> 
> We should make this customizable: file_contexts_suffix =
> to catch *.fc as well as *.cil and any future high level file_context suffixes
> When this suffix is used we should also alway take "file_contexts" into account as this is where to look in monolitic policy
> 
> > 4. 
> > return self.diff_relative("/policy/mls", other_source) # these should be customizable
> 
> mls_constraints =
> 
> > return self.diff_relative("/policy/mcs", other_source) # these should be customizable
> 
> mcs_constraints =
> 
> > return self.diff_relative("/policy/constraints", other_source) # these should be customizable
> 
> constraints =
> 
> or maybe dont even differentiate between the various different constraints and just pile them all together in:
> 
> constraints = [ "", "", "", ... ]

As a matter of fact, constraints could be anywhere. So probably better to find a different way to get all the constraints

in cil you can have your constraints whereever you want. For example : I have my dbus constraints in dbus.cil with the other dbus policy
This is not unique. This is how it should be with CIL or any high level policy on top of CIL
it was a limitation of module policy that we couldnt have constraints in modules in the past

> 
> This is because there may be other constraints (for example i have role-base access control seperation constraints)
> 
> > 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = ... etc
> 
> I do not consider Linux access vectors to be customizable, unlike types ,attributes, booleans, tunables etc)
> 
> So one does not have to worry about the hard coding of classes and permission, However i would probably still try to find a way
> make that more easily customizable. Because new permissions get added to existing classes and if you have you access vector declarations in a single place then that is easier to maintain then when you have to add then in code scathered accross the project
> 
> > 
> > > 
> > > Thanks - Karl
> > > 
> > > > Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> > > > 
> > > >> 
> > > >> Thanks - Karl
> > > >> 
> > > >>> 
> > > >>>> 
> > > >>>> -- 
> > > >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > >>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > > >>>> Dominick Grift
> > > >>> 
> > > >>> 
> > > >>> 
> > > >>> -- 
> > > >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > > >>> Dominick Grift
> > > >> 
> > > > 
> > > > -- 
> > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > > > Dominick Grift
> > > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]


> On May 8, 2017, at 5:47 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
>> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
>>> 
>>>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
>>>> 
>> 
>>> 
>>> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
>> 
>> I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
>> 
>> ill point out some:
>> 
>> 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> 
> We should make this customizable something like: source_policy_suffix =
> 
> Because we would need to catch *.conf , *.te , *.cil and any future high level source policy files that leverage cil
> 

Like I said, I just renamed the PolicySource object to reflect that it’s specific to reference policy. Feel free to send a patch adding a DSSP object that implements the changes that you think are needed.

[deleted many similar requests]

> 
>> 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = ... etc
> 
> I do not consider Linux access vectors to be customizable, unlike types ,attributes, booleans, tunables etc)
> 

I know what you mean, but I have to point out that the domain attribute has been much more stable across many different operating systems than the object classes and access vectors. 

Thanks - Karl



[-- Attachment #2: Type: text/html, Size: 7573 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Joshua Brindle]

Karl MacMillan wrote:
<snip>
>
>>> 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = ... etc
>> I do not consider Linux access vectors to be customizable, unlike types ,attributes, booleans, tunables etc)
>>
>
> I know what you mean, but I have to point out that the domain attribute has been much more stable across many different operating systems than the object classes and access vectors.

This is true, and being able to specify subject types and object types 
(processes and files are instances of those) could make this useful for 
analysis of e.g., Xen policies... Not that I see a huge demand for that 
sort of thing

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 8, 2017, at 4:40 PM, Dominick Grift <dac.override@gmail.com> wrote:
> 
> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
>> 
>>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
>>> 
>>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
>>>> 
>>>>> 
>>>> 
>>>> I think it’s best to think of these as having three basic layers:
>>>> 
>>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
>>>> 
>>>> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
>>>> 
>>>> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
>>>> 
>>>> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
>>> 
>>> I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
>> 
>> We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
>> 
>>> Thank you for giving me your opinion. At least now I know where I stand.
>> 
>> Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> 
> I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> 

Shrug. SELinux is “bigger” than the current set of object classes and access vectors or the components of the security context. Yet we still have to write policy using those. Abstraction is a useful tool, but too much abstraction interferes with getting work done clearly.

Ultimately SPAN has to make some assumptions about how policy works to do any higher-level analysis (a problem that SETools doesn’t really have because it doesn’t do much of the higher-level analysis that I’m talking about). Making that somewhat configurable is fine, but not at the cost of comprehensibility. When we hit that point it’s better just to split the higher-level analysis methods into different versions based the policy type.

Either way, I’m open to including the customizations or separate code in SPAN.

>> 
>> I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
>> 
>> And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> 
> Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is “subj.subj_type_attribute"
> 

This is just my opinion of course, but it seems counterproductive to put what is clearly a global concept into a namespace. And _every_ policy that I know of for something like two decades has had a domain attribute. Do you really get enough benefits out of this change to outweigh the pain caused by changing such a long-running convention?

> So if the configuration file would have something like:
> 
> # process_types = domain
> 
> Then i would be happy because then i could edit it like:
> 
> process_types = subj.subj_type_attribute
> 

I just committed a change that adds a domain_attribute instance variable into the Policy class, allowing you to change this. You would use it like this:

p = span.load_policy(“some_dssp_policy.cil”)
p.domain_attribute = “subj.subj_type_attribute”
p.domain_types() # This now looks for the subj.subj_type_attribute instead of domain

If you want to send patches for similar changes I’ll be happy to review them.

Note that a configuration file is not really appropriate I don’t think. This is a Python library and it’s better to just do the configuration in code. If you have several changes that are needed for a dssp policy feel free to propose a load_dssp_policy top-level function that sets the defaults as necessary.

>> 
>>> I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
>> 
>> I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> 
> Let me rephrase then: "not to the fullest extent"
> 
> But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.”
> 

These are not “bugs” they are design decisions to prioritize the policies that are on shipping systems.

I’m open to contributions, but can’t really add support for DSSP on my own as I have no experience with it.

>> 
>> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> 
> I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> 
> ill point out some:
> 
> 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
> 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
> 4. 
> return self.diff_relative("/policy/mls", other_source) # these should be customizable
> return self.diff_relative("/policy/mcs", other_source) # these should be customizable
> return self.diff_relative("/policy/constraints", other_source) # these should be customizable

These are from the small policy source object - which is very tied to reference policy. I’ve just renamed that to RefPolicySource. Feel free to send a patch to add a DsspPolicySource.

> 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = … etc
> 

The only one I really saw was domain, which I’ve made configurable. But I didn’t search exhaustively. Again, feel free to send patches.

Thanks - Karl

>> 
>> Thanks - Karl
>> 
>>> Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
>>> 
>>>> 
>>>> Thanks - Karl
>>>> 
>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>>>>>> Dominick Grift
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>>>>> Dominick Grift
>>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>>> Dominick Grift
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 11430 bytes --]

On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> >> 
> >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> >>> 
> >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> >>>> 
> >>>>> 
> >>>> 
> >>>> I think it’s best to think of these as having three basic layers:
> >>>> 
> >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> >>>> 
> >>>> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> >>>> 
> >>>> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> >>>> 
> >>>> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> >>> 
> >>> I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> >> 
> >> We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> >> 
> >>> Thank you for giving me your opinion. At least now I know where I stand.
> >> 
> >> Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> > 
> > I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> > The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> > What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> > 
> 
> Shrug. SELinux is “bigger” than the current set of object classes and access vectors or the components of the security context. Yet we still have to write policy using those. Abstraction is a useful tool, but too much abstraction interferes with getting work done clearly.
> 
> Ultimately SPAN has to make some assumptions about how policy works to do any higher-level analysis (a problem that SETools doesn’t really have because it doesn’t do much of the higher-level analysis that I’m talking about). Making that somewhat configurable is fine, but not at the cost of comprehensibility. When we hit that point it’s better just to split the higher-level analysis methods into different versions based the policy type.
> 
> Either way, I’m open to including the customizations or separate code in SPAN.
> 
> >> 
> >> I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> >> 
> >> And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> > 
> > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is “subj.subj_type_attribute"
> > 
> 
> This is just my opinion of course, but it seems counterproductive to put what is clearly a global concept into a namespace. And _every_ policy that I know of for something like two decades has had a domain attribute. Do you really get enough benefits out of this change to outweigh the pain caused by changing such a long-running convention?
> 
> > So if the configuration file would have something like:
> > 
> > # process_types = domain
> > 
> > Then i would be happy because then i could edit it like:
> > 
> > process_types = subj.subj_type_attribute
> > 
> 
> I just committed a change that adds a domain_attribute instance variable into the Policy class, allowing you to change this. You would use it like this:
> 
> p = span.load_policy(“some_dssp_policy.cil”)
> p.domain_attribute = “subj.subj_type_attribute”
> p.domain_types() # This now looks for the subj.subj_type_attribute instead of domain

Thanks!

I spent all day working on my analysis of unconfined access: https://github.com/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.ipynb

Its not so easy:

1. first i had to get familiar with notebook and aqcuire in a such a way that i can use it
2. then i had to get familiar with span
3. in order to use span i have to get familiar with python (i do not like python but this endevour does push me to play with it more)
4. then i have to actually use span to get some useful and much needed analysis done in DSSP
5. then i have to maintain DSSP is self (which isnt an attempt to write cil policy from scratch i might add, its a policy that i use)

if and once i get to any significant extent productive with python then span will probably be the first project i contribute to. Since my python skill is 0.75 and since theres only 24 hours in a day it probably, unfortunately, wont happen overnight


As for the domain vs subj.subj_type_attribute issue: i think it is worth it yes.

Having a small set of consistent type attributes that get additional meaning by using them in different name spaces.

subj.subj_type_attribute (any process)
user.subj_type_attribute (any user process
user.unpriv.subj_type_attribute (any unpriv user process)

i have hundreds of these in DSSP. Theyre pretty much all consistently named.

> 
> If you want to send patches for similar changes I’ll be happy to review them.
> 
> Note that a configuration file is not really appropriate I don’t think. This is a Python library and it’s better to just do the configuration in code. If you have several changes that are needed for a dssp policy feel free to propose a load_dssp_policy top-level function that sets the defaults as necessary.
> 
> >> 
> >>> I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> >> 
> >> I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> > 
> > Let me rephrase then: "not to the fullest extent"
> > 
> > But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.”
> > 
> 
> These are not “bugs” they are design decisions to prioritize the policies that are on shipping systems.
> 
> I’m open to contributions, but can’t really add support for DSSP on my own as I have no experience with it.
> 
> >> 
> >> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> > 
> > I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> > 
> > ill point out some:
> > 
> > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> > 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
> > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
> > 4. 
> > return self.diff_relative("/policy/mls", other_source) # these should be customizable
> > return self.diff_relative("/policy/mcs", other_source) # these should be customizable
> > return self.diff_relative("/policy/constraints", other_source) # these should be customizable
> 
> These are from the small policy source object - which is very tied to reference policy. I’ve just renamed that to RefPolicySource. Feel free to send a patch to add a DsspPolicySource.
> 
> > 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = … etc
> > 
> 
> The only one I really saw was domain, which I’ve made configurable. But I didn’t search exhaustively. Again, feel free to send patches.
> 
> Thanks - Karl
> 
> >> 
> >> Thanks - Karl
> >> 
> >>> Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> >>> 
> >>>> 
> >>>> Thanks - Karl
> >>>> 
> >>>>> 
> >>>>>> 
> >>>>>> -- 
> >>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> >>>>>> Dominick Grift
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> -- 
> >>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> >>>>> Dominick Grift
> >>>> 
> >>> 
> >>> -- 
> >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> >>> Dominick Grift
> >> 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 12714 bytes --]

On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote:
> On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> > 
> > > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > 
> > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > >> 
> > >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > >>> 
> > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> > >>>> 
> > >>>>> 
> > >>>> 
> > >>>> I think it’s best to think of these as having three basic layers:
> > >>>> 
> > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> > >>>> 
> > >>>> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> > >>>> 
> > >>>> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> > >>>> 
> > >>>> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> > >>> 
> > >>> I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> > >> 
> > >> We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> > >> 
> > >>> Thank you for giving me your opinion. At least now I know where I stand.
> > >> 
> > >> Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> > > 
> > > I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> > > The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> > > What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> > > 
> > 
> > Shrug. SELinux is “bigger” than the current set of object classes and access vectors or the components of the security context. Yet we still have to write policy using those. Abstraction is a useful tool, but too much abstraction interferes with getting work done clearly.
> > 
> > Ultimately SPAN has to make some assumptions about how policy works to do any higher-level analysis (a problem that SETools doesn’t really have because it doesn’t do much of the higher-level analysis that I’m talking about). Making that somewhat configurable is fine, but not at the cost of comprehensibility. When we hit that point it’s better just to split the higher-level analysis methods into different versions based the policy type.
> > 
> > Either way, I’m open to including the customizations or separate code in SPAN.
> > 
> > >> 
> > >> I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> > >> 
> > >> And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> > > 
> > > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is “subj.subj_type_attribute"
> > > 
> > 
> > This is just my opinion of course, but it seems counterproductive to put what is clearly a global concept into a namespace. And _every_ policy that I know of for something like two decades has had a domain attribute. Do you really get enough benefits out of this change to outweigh the pain caused by changing such a long-running convention?

With DSSP, except for the initial sids i suppose, nothing is global. (see dssp-base) It is modular and if you dont want to differentiate between subject and object than you can do so with DSSP. It is modular. just remove the subject module and its dependencies. CIL allows one to do this because it makes dependency resolving usable.

the subj.subj_type_attribute might sound useless but its part of the bigger picture. Consistency accros the policy (another core concept of dssp is comprehensiveness. A lot is the same and this makes writing policy an intuitive experience. only the name spaces are different. the macros , attributes are all the same. Not going to deviate from that for "domain"

> > 
> > > So if the configuration file would have something like:
> > > 
> > > # process_types = domain
> > > 
> > > Then i would be happy because then i could edit it like:
> > > 
> > > process_types = subj.subj_type_attribute
> > > 
> > 
> > I just committed a change that adds a domain_attribute instance variable into the Policy class, allowing you to change this. You would use it like this:
> > 
> > p = span.load_policy(“some_dssp_policy.cil”)
> > p.domain_attribute = “subj.subj_type_attribute”
> > p.domain_types() # This now looks for the subj.subj_type_attribute instead of domain
> 
> Thanks!
> 
> I spent all day working on my analysis of unconfined access: https://github.com/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.ipynb
> 
> Its not so easy:
> 
> 1. first i had to get familiar with notebook and aqcuire in a such a way that i can use it
> 2. then i had to get familiar with span
> 3. in order to use span i have to get familiar with python (i do not like python but this endevour does push me to play with it more)
> 4. then i have to actually use span to get some useful and much needed analysis done in DSSP
> 5. then i have to maintain DSSP is self (which isnt an attempt to write cil policy from scratch i might add, its a policy that i use)
> 
> if and once i get to any significant extent productive with python then span will probably be the first project i contribute to. Since my python skill is 0.75 and since theres only 24 hours in a day it probably, unfortunately, wont happen overnight
> 
> 
> As for the domain vs subj.subj_type_attribute issue: i think it is worth it yes.
> 
> Having a small set of consistent type attributes that get additional meaning by using them in different name spaces.
> 
> subj.subj_type_attribute (any process)
> user.subj_type_attribute (any user process
> user.unpriv.subj_type_attribute (any unpriv user process)
> 
> i have hundreds of these in DSSP. Theyre pretty much all consistently named.
> 
> > 
> > If you want to send patches for similar changes I’ll be happy to review them.
> > 
> > Note that a configuration file is not really appropriate I don’t think. This is a Python library and it’s better to just do the configuration in code. If you have several changes that are needed for a dssp policy feel free to propose a load_dssp_policy top-level function that sets the defaults as necessary.
> > 
> > >> 
> > >>> I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> > >> 
> > >> I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> > > 
> > > Let me rephrase then: "not to the fullest extent"
> > > 
> > > But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.”
> > > 
> > 
> > These are not “bugs” they are design decisions to prioritize the policies that are on shipping systems.
> > 
> > I’m open to contributions, but can’t really add support for DSSP on my own as I have no experience with it.
> > 
> > >> 
> > >> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> > > 
> > > I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> > > 
> > > ill point out some:
> > > 
> > > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> > > 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
> > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
> > > 4. 
> > > return self.diff_relative("/policy/mls", other_source) # these should be customizable
> > > return self.diff_relative("/policy/mcs", other_source) # these should be customizable
> > > return self.diff_relative("/policy/constraints", other_source) # these should be customizable
> > 
> > These are from the small policy source object - which is very tied to reference policy. I’ve just renamed that to RefPolicySource. Feel free to send a patch to add a DsspPolicySource.
> > 
> > > 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = … etc
> > > 
> > 
> > The only one I really saw was domain, which I’ve made configurable. But I didn’t search exhaustively. Again, feel free to send patches.
> > 
> > Thanks - Karl
> > 
> > >> 
> > >> Thanks - Karl
> > >> 
> > >>> Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> > >>> 
> > >>>> 
> > >>>> Thanks - Karl
> > >>>> 
> > >>>>> 
> > >>>>>> 
> > >>>>>> -- 
> > >>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > >>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > >>>>>> Dominick Grift
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>>> -- 
> > >>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > >>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > >>>>> Dominick Grift
> > >>>> 
> > >>> 
> > >>> -- 
> > >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > >>> Dominick Grift
> > >> 
> > > 
> > > -- 
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > Dominick Grift
> > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 14323 bytes --]

On Tue, May 09, 2017 at 06:47:55PM +0200, Dominick Grift wrote:
> On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote:
> > On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote:
> > > 
> > > > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > > 
> > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > > >> 
> > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > >>> 
> > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> > > >>>> 
> > > >>>>> 
> > > >>>> 
> > > >>>> I think it’s best to think of these as having three basic layers:
> > > >>>> 
> > > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
> > > >>>> 
> > > >>>> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
> > > >>>> 
> > > >>>> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
> > > >>>> 
> > > >>>> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
> > > >>> 
> > > >>> I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
> > > >> 
> > > >> We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
> > > >> 
> > > >>> Thank you for giving me your opinion. At least now I know where I stand.
> > > >> 
> > > >> Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
> > > > 
> > > > I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp
> > > > The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect.
> > > > What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect)
> > > > 
> > > 
> > > Shrug. SELinux is “bigger” than the current set of object classes and access vectors or the components of the security context. Yet we still have to write policy using those. Abstraction is a useful tool, but too much abstraction interferes with getting work done clearly.
> > > 
> > > Ultimately SPAN has to make some assumptions about how policy works to do any higher-level analysis (a problem that SETools doesn’t really have because it doesn’t do much of the higher-level analysis that I’m talking about). Making that somewhat configurable is fine, but not at the cost of comprehensibility. When we hit that point it’s better just to split the higher-level analysis methods into different versions based the policy type.
> > > 
> > > Either way, I’m open to including the customizations or separate code in SPAN.
> > > 
> > > >> 
> > > >> I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
> > > >> 
> > > >> And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
> > > > 
> > > > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is “subj.subj_type_attribute"
> > > > 
> > > 
> > > This is just my opinion of course, but it seems counterproductive to put what is clearly a global concept into a namespace. And _every_ policy that I know of for something like two decades has had a domain attribute. Do you really get enough benefits out of this change to outweigh the pain caused by changing such a long-running convention?
> 
> With DSSP, except for the initial sids i suppose, nothing is global. (see dssp-base) It is modular and if you dont want to differentiate between subject and object than you can do so with DSSP. It is modular. just remove the subject module and its dependencies. CIL allows one to do this because it makes dependency resolving usable.
> 
> the subj.subj_type_attribute might sound useless but its part of the bigger picture. Consistency accros the policy (another core concept of dssp is comprehensiveness. A lot is the same and this makes writing policy an intuitive experience. only the name spaces are different. the macros , attributes are all the same. Not going to deviate from that for "domain"
> 
> > > 
> > > > So if the configuration file would have something like:
> > > > 
> > > > # process_types = domain
> > > > 
> > > > Then i would be happy because then i could edit it like:
> > > > 
> > > > process_types = subj.subj_type_attribute
> > > > 
> > > 
> > > I just committed a change that adds a domain_attribute instance variable into the Policy class, allowing you to change this. You would use it like this:
> > > 
> > > p = span.load_policy(“some_dssp_policy.cil”)
> > > p.domain_attribute = “subj.subj_type_attribute”
> > > p.domain_types() # This now looks for the subj.subj_type_attribute instead of domain
> > 
> > Thanks!
> > 
> > I spent all day working on my analysis of unconfined access: https://github.com/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.ipynb
> > 
> > Its not so easy:
> > 
> > 1. first i had to get familiar with notebook and aqcuire in a such a way that i can use it
> > 2. then i had to get familiar with span
> > 3. in order to use span i have to get familiar with python (i do not like python but this endevour does push me to play with it more)
> > 4. then i have to actually use span to get some useful and much needed analysis done in DSSP
> > 5. then i have to maintain DSSP is self (which isnt an attempt to write cil policy from scratch i might add, its a policy that i use)
> > 
> > if and once i get to any significant extent productive with python then span will probably be the first project i contribute to. Since my python skill is 0.75 and since theres only 24 hours in a day it probably, unfortunately, wont happen overnight
> > 
> > 
> > As for the domain vs subj.subj_type_attribute issue: i think it is worth it yes.
> > 
> > Having a small set of consistent type attributes that get additional meaning by using them in different name spaces.
> > 
> > subj.subj_type_attribute (any process)
> > user.subj_type_attribute (any user process
> > user.unpriv.subj_type_attribute (any unpriv user process)
> > 
> > i have hundreds of these in DSSP. Theyre pretty much all consistently named.
> > 
> > > 
> > > If you want to send patches for similar changes I’ll be happy to review them.
> > > 
> > > Note that a configuration file is not really appropriate I don’t think. This is a Python library and it’s better to just do the configuration in code. If you have several changes that are needed for a dssp policy feel free to propose a load_dssp_policy top-level function that sets the defaults as necessary.
> > > 
> > > >> 
> > > >>> I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
> > > >> 
> > > >> I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
> > > > 
> > > > Let me rephrase then: "not to the fullest extent"
> > > > 
> > > > But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.”
> > > > 
> > > 
> > > These are not “bugs” they are design decisions to prioritize the policies that are on shipping systems.
> > > 
> > > I’m open to contributions, but can’t really add support for DSSP on my own as I have no experience with it.

I am not asking you to support DSSP (how can i make this any more clear). I am just asking to not tie your product to a any single policy but instead to set the right example.

This idea of yours to split the policy model specifics out of base sounds really good to me. Nothing wrong with refpolicy specific functionality, but just be clear about it and make it optional

I am worried about the precendence here. It starts with a project here and there hard-coding policy specifics and branding it "selinux", then some of that stuff slips into the upstream and before you know it selinux users space becomes unusable with anything but refpolicy unless you strip out half of it like sds did with seandroid.

And then one wonders why SELinux is judged by the policy it is enforcing , rather than for what it is: a flexible, customizable framework that allows for fine grained MAC

> > > 
> > > >> 
> > > >> And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
> > > > 
> > > > I agree, and ive said that when I said: "a few rough edges" Its close the usable with DSSP. It just needs to deal with some of the current assumptions:
> > > > 
> > > > ill point out some:
> > > > 
> > > > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed files?
> > > > 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
> > > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context specs in the .cil suffixed file
> > > > 4. 
> > > > return self.diff_relative("/policy/mls", other_source) # these should be customizable
> > > > return self.diff_relative("/policy/mcs", other_source) # these should be customizable
> > > > return self.diff_relative("/policy/constraints", other_source) # these should be customizable
> > > 
> > > These are from the small policy source object - which is very tied to reference policy. I’ve just renamed that to RefPolicySource. Feel free to send a patch to add a DsspPolicySource.
> > > 
> > > > 5. any references to type attributes should be customizable: ie. process_types = ... filesystem_types = … etc
> > > > 
> > > 
> > > The only one I really saw was domain, which I’ve made configurable. But I didn’t search exhaustively. Again, feel free to send patches.

I think your idea is better. i.e. split the refpolicy specific bits out and put it in python3-span-refpolicy

> > > 
> > > Thanks - Karl
> > > 
> > > >> 
> > > >> Thanks - Karl
> > > >> 
> > > >>> Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
> > > >>> 
> > > >>>> 
> > > >>>> Thanks - Karl
> > > >>>> 
> > > >>>>> 
> > > >>>>>> 
> > > >>>>>> -- 
> > > >>>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > >>>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > > >>>>>> Dominick Grift
> > > >>>>> 
> > > >>>>> 
> > > >>>>> 
> > > >>>>> -- 
> > > >>>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > >>>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> > > >>>>> Dominick Grift
> > > >>>> 
> > > >>> 
> > > >>> -- 
> > > >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > >>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > > >>> Dominick Grift
> > > >> 
> > > > 
> > > > -- 
> > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > > > Dominick Grift
> > > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> <snip>
> 
> > The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> > 
> 
> Of course, it is an analysis of a refpolicy-based policy. If you want to
> analyze a different policy (e.g., Android or home-rolled) you will have to
> change out all of the type sets, etc.
> 
> You can't make a magic generic analysis script without knowing how key parts
> of the system work and what types are associated with those components.
> 
> 

Can it not be made so that we can override these ps.* file suffixes (.cil) and paths without the need to recompile/reinstall ipynb?

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]