From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v45IRAc5026513 for ; Fri, 5 May 2017 14:27:10 -0400 Received: by mail-qt0-f176.google.com with SMTP id m91so11778938qte.3 for ; Fri, 05 May 2017 11:27:07 -0700 (PDT) From: Karl MacMillan Content-Type: multipart/alternative; boundary="Apple-Mail=_8B270DE7-CC5C-44AA-9D2D-318AA7961F98" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Announcing SPAN: SELinux Policy Analysis Notebook Message-Id: Date: Fri, 5 May 2017 14:27:05 -0400 Cc: Brandon Whalen , Spencer Shimko , Chris PeBenito , dac To: selinux@tycho.nsa.gov List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_8B270DE7-CC5C-44AA-9D2D-318AA7961F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d like to announce SPAN - SELinux Policy Analysis Notebook = (https://github.com/QuarkSecurity/SPAN/ = ). This is a Jupyter notebook = based environment for SELinux policy analysis that let=E2=80=99s you mix = queries, Python code, and Markdown formatted notes into an executable = document. It=E2=80=99s 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=E2=80=99ve seen for real policy analysis (and I=E2=80=99= 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/example= s/Span%20Example.ipynb# = If you=E2=80=99ve 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 = . = There is also the more official (and boring) introduction: = 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= --Apple-Mail=_8B270DE7-CC5C-44AA-9D2D-318AA7961F98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99d like to announce SPAN - SELinux Policy Analysis = Notebook (https://github.com/QuarkSecurity/SPAN/). This is a = Jupyter notebook based environment for SELinux policy analysis that = let=E2=80=99s you mix queries, Python code, and Markdown formatted notes = into an executable document. It=E2=80=99s 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=E2=80=99v= e seen for real policy analysis (and I=E2=80=99ve 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/mas= ter/examples/Span%20Example.ipynb#

If = you=E2=80=99ve 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.ipy= nb. There is also the more official (and boring) = introduction: https://jupyter-notebook-beginner-guide.readthedocs.io/en/lates= t/.

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
= --Apple-Mail=_8B270DE7-CC5C-44AA-9D2D-318AA7961F98-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v46E48AD014310 for ; Sat, 6 May 2017 10:04:08 -0400 Received: by mail-wm0-f45.google.com with SMTP id b84so14562891wmh.0 for ; Sat, 06 May 2017 07:04:01 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id n55sm4463582edd.65.2017.05.06.07.03.59 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 06 May 2017 07:03:59 -0700 (PDT) Date: Sat, 6 May 2017 16:03:58 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170506140358.GA21008@julius> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" In-Reply-To: List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 05, 2017 at 02:27:05PM -0400, Karl MacMillan wrote: > I=E2=80=99d like to announce SPAN - SELinux Policy Analysis Notebook (htt= ps://github.com/QuarkSecurity/SPAN/ ). This is a Jupyter notebook based environment for SELinux policy analysi= s that let=E2=80=99s you mix queries, Python code, and Markdown formatted n= otes into an executable document. It=E2=80=99s an extension of SETools 4. >=20 > Using SPAN within Jupyter notebook is an amazingly productive way to do p= olicy analysis. I really think that this is the most productive environment= that I=E2=80=99ve seen for real policy analysis (and I=E2=80=99ve been wor= king on SELinux policy analysis and tools for almost 15 years). The ability= to quickly create custom tools to answer hard questions combined inline wi= th well-formatted documentation makes a huge difference. >=20 > SPAN has been used so far to analyze 3 large, complex, custom systems wit= h very large policies (hundreds of custom domains). The analysis was of muc= h better quality and it took much less time because of SPAN. >=20 > If you just want to see what this looks like, you can see an example onli= ne (though the code is not executable): >=20 > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/exampl= es/Span%20Example.ipynb# >=20 > If you=E2=80=99ve not seen Jupyter notebooks, they are a very popular too= l for data science. Jupyter notebooks are an interactive environment that l= et you write text (in Markdown) and code together. You can get a feel for w= hat's possible in this awesome notebook on Regex Golf from XKCD: http://nbv= iewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb . There is also the more of= ficial (and boring) introduction: https://jupyter-notebook-beginner-guide.r= eadthedocs.io/en/latest/ . >=20 > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and Bra= ndon Whalen from Quark Security. And, of course, this is built on SETools 4= which is maintained by Chris PeBinito. >=20 > Thanks - Karl Nice! Unfornately i could not, which my limited capacity, get it to work. H= ere 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"=20 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 e= xample: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_t= o_word.py in ()" --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkN18kACgkQJXSOVTf5 R2mlAQv/au3k06ge1VmnMZKcA9Yonpr+a5G9gMbiUIa9AqCLox0PGmUCQASEirse 4oZWnzqahxJHoT2Cn61Abe6v5Yr01hmqPrBJWQ1YIPQevudNOFO4goWKGgy9+V/j 9Uz/o5KUlk4jEFSQRp0G2TW+tjG+VhSlNZv/7y1bsfI1qbbyUtraggPrADH9c4Ia AHg6vPq+k15+YN76W48XUIpyeq+F85LMXo0pgXXSS49QmdEs8anJ8vL3Ujdm+pbu THM8/xNz1xX/efxOLQxDw8chE5VJk2FuEP4CS5JdS6CN0bnYa5S6zGh5BfwLFGRD rOwWGhTJAkUxJBE3I9Fq4kUnFYBSV2uqsb/OUrmh3CqJth7+WjST0dpWde9eKXf8 e1M+HHRqjjZ7sZ94y2h0mY8VR0vULs/gd5skFuZK2kA9BxHAWxU6Tjj38590SOUX 8AbsnZhmIg/8qKC1PqeTID0JvuYUcrwW+HWwYc3uJE4NXwk8NZ7re2HjgBmrPCCl miTVsAh5 =riKy -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v46GK4PW012652 for ; Sat, 6 May 2017 12:20:04 -0400 Received: by mail-wm0-f45.google.com with SMTP id b84so16172844wmh.0 for ; Sat, 06 May 2017 09:20:00 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id i28sm2582098ede.38.2017.05.06.09.19.58 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 06 May 2017 09:19:58 -0700 (PDT) Date: Sat, 6 May 2017 18:19:56 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170506161956.GA20145@julius> References: <20170506140358.GA21008@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" In-Reply-To: <20170506140358.GA21008@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=E2=80=99d like to announce SPAN - SELinux Policy Analysis Notebook (h= ttps://github.com/QuarkSecurity/SPAN/ ). This is a Jupyter notebook based environment for SELinux policy analy= sis that let=E2=80=99s you mix queries, Python code, and Markdown formatted= notes into an executable document. It=E2=80=99s an extension of SETools 4. > >=20 > > Using SPAN within Jupyter notebook is an amazingly productive way to do= policy analysis. I really think that this is the most productive environme= nt that I=E2=80=99ve seen for real policy analysis (and I=E2=80=99ve been w= orking on SELinux policy analysis and tools for almost 15 years). The abili= ty to quickly create custom tools to answer hard questions combined inline = with well-formatted documentation makes a huge difference. > >=20 > > SPAN has been used so far to analyze 3 large, complex, custom systems w= ith very large policies (hundreds of custom domains). The analysis was of m= uch better quality and it took much less time because of SPAN. > >=20 > > If you just want to see what this looks like, you can see an example on= line (though the code is not executable): > >=20 > > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/exam= ples/Span%20Example.ipynb# > >=20 > > If you=E2=80=99ve not seen Jupyter notebooks, they are a very popular t= ool 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://n= bviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb . There is also the more = official (and boring) introduction: https://jupyter-notebook-beginner-guide= =2Ereadthedocs.io/en/latest/ . > >=20 > > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and B= randon Whalen from Quark Security. And, of course, this is built on SETools= 4 which is maintained by Chris PeBinito. > >=20 > > Thanks - Karl >=20 > Nice! Unfornately i could not, which my limited capacity, get it to work.= Here is what i tried: >=20 > Fedora 26 (alpha): > sudo dnf install setools setools-console libselinux-python3 pandoc which > git clone https://github.com/quarcksecurity/span && cd span && pip3 insta= ll . --user > cd examples && jupyter-notebook >=20 > As soon as i try to run any "cell" or do "restart kernel and run all cell= s" it throws stack traces about "ModuleNotFoundError" (import span as se" a= nd "from sh import pandoc"=20 >=20 > All the stuff seems to be installed properly in ~/.local/lib/python3.6/si= te-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 ()" I dont know exactly what the issue is but after installing the following fr= om 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 i= n the python_requirements.txt, but even after adding it there it still did = not work >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkN96gACgkQJXSOVTf5 R2lqqAwAjisx8T0PDm6q5WOnkoOi5GsmU1NXAFGgo4xDI+ah8KOPBho/jvBl//pF IMqnilraRCq1/UgZY30TELCjo9ulw4+5W+Ecq7eJ+St+VzJs9eaPDaISAc3iS/QM 748nm8/s5TOhzB4kqZ5UskFRPF62uHbU3VeINbx1edM48fu6fdew8i7EHmcD7JTg HJPmZJ9/yVuR8fVi3v5FnVHnY9hV5uj6rHwGUjHM0q1nNcNi035mOwG5VmhK8Wp2 e7AQzXS6d1e4wOtNx+V+zEvTeDgasMKZ2ZvX7DXJCVJjWrs7CUVgP6gXhB3550zR rImYvZIr1+v543Ub8m1HIEx7D/gCPOL1nuuJlz/PUqbIPtXs56WZvEE1MI7UNhCX yTLmeJ94POPSypYmNpTMtfckwOAaeHi3gD5wcuh8RRe/+moPaPuf6SlvHWW77Pn5 U18b8paVySlLKPm4tLIMBrFCE1IDtlBqfnMZ48wjCszznUNk9BdYqesdMzb7mTx9 TgSyAo9G =nobM -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v46HJTTF026132 for ; Sat, 6 May 2017 13:19:29 -0400 Received: by mail-wm0-f54.google.com with SMTP id u65so46897796wmu.1 for ; Sat, 06 May 2017 10:19:24 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id h29sm5751260eda.45.2017.05.06.10.19.22 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 06 May 2017 10:19:22 -0700 (PDT) Date: Sat, 6 May 2017 19:19:20 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170506171920.GB20145@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" In-Reply-To: <20170506161956.GA20145@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=E2=80=99d like to announce SPAN - SELinux Policy Analysis Notebook = (https://github.com/QuarkSecurity/SPAN/ ). This is a Jupyter notebook based environment for SELinux policy ana= lysis that let=E2=80=99s you mix queries, Python code, and Markdown formatt= ed notes into an executable document. It=E2=80=99s an extension of SETools = 4. > > >=20 > > > Using SPAN within Jupyter notebook is an amazingly productive way to = do policy analysis. I really think that this is the most productive environ= ment that I=E2=80=99ve seen for real policy analysis (and I=E2=80=99ve been= working on SELinux policy analysis and tools for almost 15 years). The abi= lity to quickly create custom tools to answer hard questions combined inlin= e with well-formatted documentation makes a huge difference. > > >=20 > > > 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. > > >=20 > > > If you just want to see what this looks like, you can see an example = online (though the code is not executable): > > >=20 > > > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/ex= amples/Span%20Example.ipynb# > > >=20 > > > If you=E2=80=99ve not seen Jupyter notebooks, they are a very popular= tool for data science. Jupyter notebooks are an interactive environment th= at let you write text (in Markdown) and code together. You can get a feel f= or what's possible in this awesome notebook on Regex Golf from XKCD: http:/= /nbviewer.jupyter.org/url/norvig.com/ipython/xkcd1313.ipynb . There is also the mor= e official (and boring) introduction: https://jupyter-notebook-beginner-gui= de.readthedocs.io/en/latest/ . > > >=20 > > > SPAN was written by me (Karl MacMillan) along with Spencer Shimko and= Brandon Whalen from Quark Security. And, of course, this is built on SEToo= ls 4 which is maintained by Chris PeBinito. > > >=20 > > > Thanks - Karl > >=20 > > Nice! Unfornately i could not, which my limited capacity, get it to wor= k. Here is what i tried: > >=20 > > Fedora 26 (alpha): > > sudo dnf install setools setools-console libselinux-python3 pandoc which > > git clone https://github.com/quarcksecurity/span && cd span && pip3 ins= tall . --user > > cd examples && jupyter-notebook > >=20 > > As soon as i try to run any "cell" or do "restart kernel and run all ce= lls" it throws stack traces about "ModuleNotFoundError" (import span as se"= and "from sh import pandoc"=20 > >=20 > > 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 f= or example: "/home/joe/.local/lib/python3.6/site-packages/span/domain_summa= ry_to_word.py in ()" >=20 > I dont know exactly what the issue is but after installing the following = =66rom the fedora repository i seem to have it working: >=20 > python3-pypandoc > python3-pandocfilters > python3-sh >=20 > 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 di= d not work The idea is nice, unfortunately its inflexible and it has hard-references t= o reference policy all-over. It has potential but it is still rough. >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkOBZQACgkQJXSOVTf5 R2lzVgwAizpWpm9g10jkhrG0jG/xThuYMacUekt9YZi0/1i5r5pat2OByM5alL5f KcUkpUA/BkGyro6vFT3ODJR05XqRw51SzVeugf4NFLrikZ38M/JCVVnd5+Xf2LWO +OMxWRpfrbjMGVHF2TApP8lJNv5ydwaJ03vrXwOSkO1hZOh0hllv2OfVmQiIYz0k xPUE4O5m9fYFdhgQ/L+McdY+Ov3Rds8V/s1NecxGG24l0SZSC2XLGhEnV0kX0VYp HfkjrZAGHwhFERWAdu6TpUQfOpVbcAbgBCxqWpsPXjT3KJ3ak2ohDK3smHqbVW/W hrAI+pi9KRCgr7zqh10rzhCiIhXl+jiV8vNEA9Rc8q593ltA+LD/RAgYSeFoVfgP uL3k6PDKBWKBgCGVcH+Hszp1zwybIqFG0e7y7NCDq7tglXkSsii0Wk2puT4H65xA YHw7L72Lu8cxzL+XmrLdM88cin6IsF4Gu3VO9qRzULIlkIc6YTMNL5nZtI0TkuGn IpXl8zjE =Ecxb -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v479dSV5005356 for ; Sun, 7 May 2017 05:39:28 -0400 Received: by mail-wm0-f46.google.com with SMTP id b84so25381606wmh.0 for ; Sun, 07 May 2017 02:39:25 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id a56sm3481100eda.3.2017.05.07.02.39.22 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 May 2017 02:39:23 -0700 (PDT) Date: Sun, 7 May 2017 11:39:21 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170507093921.GA22381@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" In-Reply-To: <20170506171920.GB20145@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=E2=80=99d like to announce SPAN - SELinux Policy Analysis Noteboo= k (https://github.com/QuarkSecurity/SPAN/ ). This is a Jupyter notebook based environment for SELinux policy a= nalysis that let=E2=80=99s you mix queries, Python code, and Markdown forma= tted notes into an executable document. It=E2=80=99s an extension of SETool= s 4. > > > >=20 > > > > Using SPAN within Jupyter notebook is an amazingly productive way t= o do policy analysis. I really think that this is the most productive envir= onment that I=E2=80=99ve seen for real policy analysis (and I=E2=80=99ve be= en working on SELinux policy analysis and tools for almost 15 years). The a= bility to quickly create custom tools to answer hard questions combined inl= ine with well-formatted documentation makes a huge difference. > > > >=20 > > > > SPAN has been used so far to analyze 3 large, complex, custom syste= ms with very large policies (hundreds of custom domains). The analysis was = of much better quality and it took much less time because of SPAN. > > > >=20 > > > > If you just want to see what this looks like, you can see an exampl= e online (though the code is not executable): > > > >=20 > > > > https://nbviewer.jupyter.org/github/QuarkSecurity/SPAN/blob/master/= examples/Span%20Example.ipynb# > > > >=20 > > > > If you=E2=80=99ve not seen Jupyter notebooks, they are a very popul= ar 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 . There is also the m= ore official (and boring) introduction: https://jupyter-notebook-beginner-g= uide.readthedocs.io/en/latest/ . > > > >=20 > > > > SPAN was written by me (Karl MacMillan) along with Spencer Shimko a= nd Brandon Whalen from Quark Security. And, of course, this is built on SET= ools 4 which is maintained by Chris PeBinito. > > > >=20 > > > > Thanks - Karl > > >=20 > > > Nice! Unfornately i could not, which my limited capacity, get it to w= ork. Here is what i tried: > > >=20 > > > Fedora 26 (alpha): > > > sudo dnf install setools setools-console libselinux-python3 pandoc wh= ich > > > git clone https://github.com/quarcksecurity/span && cd span && pip3 i= nstall . --user > > > cd examples && jupyter-notebook > > >=20 > > > 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 s= e" and "from sh import pandoc"=20 > > >=20 > > > 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_sum= mary_to_word.py in ()" > >=20 > > I dont know exactly what the issue is but after installing the followin= g from the fedora repository i seem to have it working: > >=20 > > python3-pypandoc > > python3-pandocfilters > > python3-sh > >=20 > > So i suspect the "from sh import pandoc" was the issue because sh was n= ot in the python_requirements.txt, but even after adding it there it still = did not work >=20 > 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 differe= nt names) I have created a Fedora SPAN.spec: https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec >=20 > >=20 > > >=20 > > > --=20 > > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > > > Dominick Grift > >=20 > >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkO60QACgkQJXSOVTf5 R2nGRAv+I1yM6ZadbObj3IEARV/MH4TiTEaevx14RpDfzxcX9qKSuzf6/dQiZ0w0 dfRm1pmKEiqcs+hHVaNoGd2LHRGi+gFiDvnR6PJiFJDALlqBzsR2gj7XSi/NZzND ovmVmCwbVNOPPjHPIj+eMlqb5tWgYmGsbdq9wmEQ5g2q/CnIgCETdx+/BlE2WFAe SRqL27QLCRqPISH15KCDUcpczhUct2LtD1CbHq5lmSCc3b456rX16spu3dhxfl1V V4FATi+WQMeaGgHs1t5PgJKDFKZx85XmWUOpGAmDbf29JWOD/4hzklccvpAahjkY r2VO3wjY8WdO0N1zaPOV7UcFz2hFn0xIazdyUAVPYXU649aqwxIhBuqG8ukVL5cO 1mh5mFqCyxz+8bA4P9RyESUkkN2pL1lSvnZ2LuFIrILHc5Frul98pNT282hf6zx2 6yBRypcPmXUKrVclhEmxcR07aIXSkNkutnxp3+gAv+IPY+bXtEogzii9TnFInvIe bllb9TFC =OXaW -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v47FM8O7010982 for ; Sun, 7 May 2017 11:22:09 -0400 Received: by mail-qk0-f171.google.com with SMTP id u75so35713961qka.3 for ; Sun, 07 May 2017 08:22:05 -0700 (PDT) Received: from strange.local (50-253-7-1-static.hfc.comcastbusiness.net. [50.253.7.1]) by smtp.googlemail.com with ESMTPSA id t1sm7959874qte.67.2017.05.07.08.22.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 May 2017 08:22:03 -0700 (PDT) Message-ID: <590F3B98.406@quarksecurity.com> Date: Sun, 07 May 2017 11:22:00 -0400 From: Joshua Brindle MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> In-Reply-To: <20170506171920.GB20145@julius> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Dominick Grift wrote: > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v47Fm8bC016269 for ; Sun, 7 May 2017 11:48:08 -0400 Received: by mail-wm0-f50.google.com with SMTP id b84so30410219wmh.0 for ; Sun, 07 May 2017 08:48:03 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id t57sm5125453edb.28.2017.05.07.08.48.01 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 May 2017 08:48:01 -0700 (PDT) Date: Sun, 7 May 2017 17:47:59 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170507154759.GA31890@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" In-Reply-To: <590F3B98.406@quarksecurity.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote: > Dominick Grift wrote: > >=20 > > The idea is nice, unfortunately its inflexible and it has hard-referenc= es to reference policy all-over. It has potential but it is still rough. > >=20 >=20 > 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. >=20 > You can't make a magic generic analysis script without knowing how key pa= rts > 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= =2E 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_so= urce). I mean if youre just going to `grep -r` then why do we have to assum= e anything there and hard code file suffixed, directory structures etc etc? >=20 >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkPQasACgkQJXSOVTf5 R2nusAv+K3t47oPhMo1zBJAi3pFv0U0F38GgJPcPu2eOa0vMBFfj+ZMXpa32SEbW f7+UJJ9B/Eg7umLK3kFs9XFzOmUKCIhJatSN9ZuZFdEFmGwvVshTyc1nRLLB2tI2 ixFS5VnDmIdHF4h+bhYKCAEp8cj1L/M6rK5qhlvdk1V+9xztY53WhgheHoBI03Sm wfAmC68+j4i5/xhju9KqNat5nyXXztYf0uiVpkq2F2B/nVp34mIKeN4IfZ6I5Jw2 4KXvtsOiQXb9r+JQDDTXVKQz/T5O0OwaN/nvZmkikrcMHKf09M521f2KmJ/NLTiM u7vW0mJcD+nuZpR6jPqwiPIhYOvbUyGC9mTI4TFH5UFHN939K5qsfKufRcSLubOh dum7C8RzoXexhwi+suddT3OaUXDRRygngy1n3vN6zT6dHewDgZ9QNpFLhbj/dFq8 9C0h9RQutYgF65wJYJbSYuXZIz1L9JrOPGQq9c5xeWZd7Mdqj2qXn40ERCj0sju6 9tOPa0Rf =x13u -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v47GOF5K023680 for ; Sun, 7 May 2017 12:24:15 -0400 Received: by mail-wm0-f53.google.com with SMTP id n198so11225476wmg.0 for ; Sun, 07 May 2017 09:24:12 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id n55sm5919603edd.65.2017.05.07.09.24.10 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 May 2017 09:24:10 -0700 (PDT) Date: Sun, 7 May 2017 18:24:09 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170507162409.GB31890@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" In-Reply-To: <590F3B98.406@quarksecurity.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote: > Dominick Grift wrote: > >=20 > > The idea is nice, unfortunately its inflexible and it has hard-referenc= es to reference policy all-over. It has potential but it is still rough. > >=20 >=20 > 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. >=20 > You can't make a magic generic analysis script without knowing how key pa= rts > of the system work and what types are associated with those components. >=20 >=20 Can it not be made so that we can override these ps.* file suffixes (.cil) = and paths without the need to recompile/reinstall ipynb? --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkPSiUACgkQJXSOVTf5 R2l0swv/exKB5LI207RkymupGYslTsPOUg2M6MYQpG7sKMgYxMKoRCT06xXGROt3 peoI2ZBya4nyLLQIqWmz23i7yebkd0ZP2uwt4fnJ4l9LOYwRSXBbwgAih32CTift lLgtHmNI/RX8O/K9acV07RAk3BPHwdQQSWwGfpOtR6uQhmDk6T3+v0nCIFcnetvp DTRGh0ib0UHocQcyK4H5bRcAxd0dL5k14OOVIwQ4ICIxPD1UiBmnr/zO4wlpkawB tbUJgbZZRTK+CLQhwbq0wAR+Bn3ASwFv5RMewf/eVGnsu3arGiRAsNj/zCmYueoK 03G/R7OoKMVT3/FaoOouzEpsVBnFZ3nLdaJO+9szKsDNqa4TJIyUaV9WYKD1dM8D NW3ZwRcGnQW1yPyI4qNYHTL9fAQPfuwqNRV7pXjlXaOpMp2Cg6iHZsh8VhAGEWWZ gPCOjgO7jOhVdLUtwACHM1Gxd3GZtjUAynD294k+YsF/RKVvttOw0dRIsOllvJYY CYp4U8ON =2/N9 -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v47JgxVi031451 for ; Sun, 7 May 2017 15:43:03 -0400 Received: by mail-qk0-f174.google.com with SMTP id k74so38036870qke.1 for ; Sun, 07 May 2017 12:42:54 -0700 (PDT) Received: from strange.local (50-253-7-1-static.hfc.comcastbusiness.net. [50.253.7.1]) by smtp.googlemail.com with ESMTPSA id p20sm3592837qtf.31.2017.05.07.12.42.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 May 2017 12:42:52 -0700 (PDT) Message-ID: <590F78BA.5040800@quarksecurity.com> Date: Sun, 07 May 2017 15:42:50 -0400 From: Joshua Brindle MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> In-Reply-To: <20170507154759.GA31890@julius> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Dominick Grift wrote: > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the >> Dominick Grift wrote: >> >> >>> 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? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v47Js200001327 for ; Sun, 7 May 2017 15:54:02 -0400 Received: by mail-wm0-f54.google.com with SMTP id m123so44834830wma.0 for ; Sun, 07 May 2017 12:53:41 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id w44sm1106532edd.53.2017.05.07.12.53.39 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 May 2017 12:53:39 -0700 (PDT) Date: Sun, 7 May 2017 21:53:38 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170507195338.GC31890@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" In-Reply-To: <590F78BA.5040800@quarksecurity.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > > >=20 > > > > The idea is nice, unfortunately its inflexible and it has hard-refe= rences to reference policy all-over. It has potential but it is still rough. > > > >=20 > > > 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 ha= ve to > > > change out all of the type sets, etc. > > >=20 > > > You can't make a magic generic analysis script without knowing how ke= y parts > > > of the system work and what types are associated with those component= s. > >=20 > > What do you mean? that for example that hard-coded array of "trusted" t= ypes. Is that not just redundant. > >=20 >=20 > you mean the example trusted types? I'm not sure I understand your concer= n. 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 over= ride 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. >=20 > > Can't i just create that array myself and use it to exlude rules with t= ypes in that array? That was one does not have to hard-code it. > >=20 >=20 > 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. >=20 > I've thought about trying this on an Android policy but haven't > made it a priority. >=20 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_polic= y_source). I mean if youre just going to `grep -r` then why do we have to a= ssume anything there and hard code file suffixed, directory structures etc = etc? >=20 >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkPez0ACgkQJXSOVTf5 R2mZEQwAsAcfSZ6Ne2fWKUgiZ32wDmxhIDeUYP72oyxK+W3Fwl0Xu+sruZmw0Nmw TXLGHiTpXC/v4pfnbqtNsxKhNCIkoR6E2JmATibo45FUVCzzMuzigzQ9U0SJe5jN E9mRJ1y4f0OxEj2XD/S0zlvvD+mqNFevNH+sqNaiV29TKIlnJk3FXMUKrG4sncYf ddS1QBHAgpC2mBRrAF6dtVBdxrccvX50UsDXTAQM0PaVp0Yb6RceCKMovas81TEK c5ga9NSx+z25HXFi3ryJlfMiKdfyIrwLl/a6yZpg1+RhkKsh77gIHWgbPlxMvnhd CdePssYlg2zE2wBVQSrHqtteKjxOT3T06Haluz/uo6WaVBKYiqJAsC1qCjWklf4m 3DIucMGEZ4lYplvhkLYx4gEnHp0C0QqijWv6UXEvgqyekTTrV940eT98ofrA+pf8 qhYZ7gnTqwVt2aS+K1Gt8Y8BU98ftceUuO3v/B+8ofbxqwHk2uDZ4A2PgKXrjC6Q 8h6jr/6K =j2O5 -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v4892qeM006402 for ; Mon, 8 May 2017 05:02:52 -0400 Received: by mail-wm0-f50.google.com with SMTP id m123so56901440wma.0 for ; Mon, 08 May 2017 01:55:59 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id c2sm3922219edc.34.2017.05.08.01.55.57 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 01:55:57 -0700 (PDT) Date: Mon, 8 May 2017 10:55:55 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508085555.GA3701@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" In-Reply-To: <590F78BA.5040800@quarksecurity.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > > >=20 > > > > The idea is nice, unfortunately its inflexible and it has hard-refe= rences to reference policy all-over. It has potential but it is still rough. > > > >=20 > > > 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 ha= ve to > > > change out all of the type sets, etc. > > >=20 > > > You can't make a magic generic analysis script without knowing how ke= y parts > > > of the system work and what types are associated with those component= s. > >=20 > > What do you mean? that for example that hard-coded array of "trusted" t= ypes. Is that not just redundant. > >=20 >=20 > you mean the example trusted types? I'm not sure I understand your concer= n. >=20 > > Can't i just create that array myself and use it to exlude rules with t= ypes in that array? That was one does not have to hard-code it. > >=20 >=20 > 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. >=20 > I've thought about trying this on an Android policy but haven't made it a > priority. >=20 > > Also with regard to hardcoding the refpolicy file system (ps.load_polic= y_source). I mean if youre just going to `grep -r` then why do we have to a= ssume anything there and hard code file suffixed, directory structures etc = etc? >=20 >=20 ahh.. sorry. I just noticed that it can be overriden: p, ps, bp, bps =3D se.load_policies_from_config("policy_paths.config") so i suppose i should be able to add that file to the notebook dir and spec= ify my own paths. although that still doesnt deal with any file suffixes? (.cil) --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --ibTvN161/egqYuK8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQMpcACgkQJXSOVTf5 R2ktbAwAgZyYANimQyDqmquTL4rJdRnO7+qnB/OOMlDG6pLcLgNucOQ3Zn9e0PjS mE0o5a1Y2f3vPaJu1g3EK5K7/4KkpMAbFXhVKME5p5Vxq0D6ZtQ+E/zetczKo+CP VK/VGyEhB51QO4mcnaUqox+ppqfDwzPJAhS1YCRh1RPuisff11scXgAIRGXerH3I Z4B2PYFf+mILclC/Gj6Yy8+LUmyg6rzijbmMqFpuGWZdXW4w2nz5s5COPpXyKeOS 6PtjowKGn1Yqss5yxssRhc21RdP7NUsB2qPZeUeW7fGoF9Yeo6oS63iaCiIvaL73 /MXmknWsDf/NX5RHBNPL9+KdpeYdDWUdtrRel8i9iqHD27Fg9c9Jmj3k8ui5vXQ4 clDxmVsgVQElmc/855DJ77EaLbzoThE6KAHJEIl4uucfQTH0jhPGV0XQ69GZMcjg 4BXA6RSOb8MrjFCHLw/facLfoBtTqO/ENTJu/I4vbkJvbQNUgWXb7r3aSSTd5/p2 52Oyyz8K =RnNZ -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v489WfdW012586 for ; Mon, 8 May 2017 05:32:42 -0400 Received: by mail-wm0-f42.google.com with SMTP id b84so47608986wmh.0 for ; Mon, 08 May 2017 02:32:33 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id m9sm1944501edd.41.2017.05.08.02.32.31 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 02:32:31 -0700 (PDT) Date: Mon, 8 May 2017 11:32:29 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508093229.GB3701@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Y7xTucakfITjPcLV" In-Reply-To: <20170508085555.GA3701@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > > > > > >=20 > > > > > The idea is nice, unfortunately its inflexible and it has hard-re= ferences to reference policy all-over. It has potential but it is still rou= gh. > > > > >=20 > > > > Of course, it is an analysis of a refpolicy-based policy. If you wa= nt to > > > > analyze a different policy (e.g., Android or home-rolled) you will = have to > > > > change out all of the type sets, etc. > > > >=20 > > > > 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 compone= nts. > > >=20 > > > What do you mean? that for example that hard-coded array of "trusted"= types. Is that not just redundant. > > >=20 > >=20 > > you mean the example trusted types? I'm not sure I understand your conc= ern. > >=20 > > > 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. > > >=20 > >=20 > > It is python, you can do anything you want. The example notebook is a > > starting point, anyone doing an analysis would probably make major chan= ges > > for their analysis, which is the point. You modify the notebook to buil= d a > > usable analysis between the starting policy and the policy you are > > analyzing. > >=20 > > I've thought about trying this on an Android policy but haven't made it= a > > priority. > >=20 > > > Also with regard to hardcoding the refpolicy file system (ps.load_pol= icy_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 et= c etc? > >=20 > >=20 >=20 > ahh.. sorry. I just noticed that it can be overriden: >=20 > p, ps, bp, bps =3D se.load_policies_from_config("policy_paths.config") >=20 > so i suppose i should be able to add that file to the notebook dir and sp= ecify my own paths. >=20 > although that still doesnt deal with any file suffixes? (.cil) take for example: https://github.com/QuarkSecurity/SPAN/blob/master/span/sp= an.py#L331 "domain" is a reference policy type attribute One should expand on the "policy_paths.config" concept and allow us, via co= nfiguration files, to override all the variables (attributes, suffixes, pat= hs, identifiers, etc) So that the variables can we adjusted without the need to reinstall/recompi= le a modified SPAN Or just rename to RPAN (reference policy analysis notebook) >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --Y7xTucakfITjPcLV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQOykACgkQJXSOVTf5 R2lCzQv9FhwxYQ9HJVUws3HsJM9lMvHBQdKGEnpPPvf8p7GdODHx8gXvDg+OG50c Wb/wCrFOUvdq2gEDAFNOm08HDns9K/ZB9/P9uAfXFkMH1iSOenzmlC2ilMYrqs+p 0JRSGsUKwRf62vp2HjW6WImzgIbV9G29frgtk+CjPB2TrdtTrBdivH2wNIdFeFpu QsXnmM78zkIEKaOyx68mSJq2qcbvlW7dgN9owf7ILugJJAhItqJU1rl9HTDuHUQZ zl7jsNhipBbHEaSA7POqDSpMp5zKbReAcCZe0kvqdj6p3yBPhZNKSR0C4HmC3VnM d5zFsEohf9LhYsXvviQBtAJfQyIwUUgniGfFecIikE6kkNXbGBiBHktwDakFf5xr H7CbP/EAyrsStxZHMg7CjqB8MmRLVqJ18xBblgra9N82R6uOSWApQ05/Z8XQSabh AVs2Ulg0o8qlsHB3izJdqzC0PvZOUKlMINMQBxhUa2C2d44bGOKeMBdk02+jfsdH 5linQqjB =pRj0 -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48JNBSV021221 for ; Mon, 8 May 2017 15:23:11 -0400 Received: by mail-qt0-f172.google.com with SMTP id m91so58487189qte.3 for ; Mon, 08 May 2017 12:23:09 -0700 (PDT) From: Karl MacMillan Message-Id: <9CD79E56-C6FE-44F8-B81B-1155356E0874@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E914717A-7E05-4BAC-9FBF-B456DDD9928A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Mon, 8 May 2017 15:23:06 -0400 In-Reply-To: <20170507093921.GA22381@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <20170507093921.GA22381@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_E914717A-7E05-4BAC-9FBF-B456DDD9928A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 7, 2017, at 5:39 AM, Dominick Grift = wrote: >=20 > 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] >>>>=20 >>>> Nice! Unfornately i could not, which my limited capacity, get it to = work. Here is what i tried: >>>>=20 >>>> 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 >>>>=20 >>>> 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"=20 >>>>=20 >>>> 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 ()" >>>=20 >>> I dont know exactly what the issue is but after installing the = following from the fedora repository i seem to have it working: >>>=20 >>> python3-pypandoc >>> python3-pandocfilters >>> python3-sh >>>=20 >>> 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 >>=20 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. >=20 >=20 > Turns out that Fedora provides all the dependencies (some just have = different names) >=20 > I have created a Fedora SPAN.spec: >=20 > https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec = >=20 >=20 Thanks for making the Fedora SPEC.=20 I know it=E2=80=99s 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=E2=80=99s portable and helps = get the latest versions (which is nice for fast moving projects like = Jupyter notebook and Pandas). Karl >>=20 >>>=20 >>>>=20 >>>> --=20 >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= >>>> Dominick Grift >>>=20 >>>=20 >>>=20 >>> --=20 >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= >>> Dominick Grift >>=20 >>=20 >>=20 >> --=20 >> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= >> Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B= 02 = > Dominick Grift --Apple-Mail=_E914717A-7E05-4BAC-9FBF-B456DDD9928A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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.s= pec



Thanks for = making the Fedora SPEC. 

I know = it=E2=80=99s 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=E2=80=99s portable and helps get the latest = versions (which is nice for fast moving projects like Jupyter notebook = and Pandas).

Karl





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



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



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



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

= --Apple-Mail=_E914717A-7E05-4BAC-9FBF-B456DDD9928A-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48JWQAs024525 for ; Mon, 8 May 2017 15:32:26 -0400 Received: by mail-wm0-f51.google.com with SMTP id n198so19632536wmg.0 for ; Mon, 08 May 2017 12:32:24 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id h29sm8571561eda.45.2017.05.08.12.32.21 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 12:32:22 -0700 (PDT) Date: Mon, 8 May 2017 21:32:20 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508193220.GA7367@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <20170507093921.GA22381@julius> <9CD79E56-C6FE-44F8-B81B-1155356E0874@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" In-Reply-To: <9CD79E56-C6FE-44F8-B81B-1155356E0874@gmail.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --FCuugMFkClbJLl1L Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote: >=20 > > On May 7, 2017, at 5:39 AM, Dominick Grift wro= te: > >=20 > > 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: >=20 > [snip] >=20 > >>>>=20 > >>>> Nice! Unfornately i could not, which my limited capacity, get it to = work. Here is what i tried: > >>>>=20 > >>>> Fedora 26 (alpha): > >>>> sudo dnf install setools setools-console libselinux-python3 pandoc w= hich > >>>> git clone https://github.com/quarcksecurity/span && cd span && pip3 = install . --user > >>>> cd examples && jupyter-notebook > >>>>=20 > >>>> 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"=20 > >>>>=20 > >>>> All the stuff seems to be installed properly in ~/.local/lib/python3= =2E6/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 ()" > >>>=20 > >>> I dont know exactly what the issue is but after installing the follow= ing from the fedora repository i seem to have it working: > >>>=20 > >>> python3-pypandoc > >>> python3-pandocfilters > >>> python3-sh > >>>=20 > >>> 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 stil= l did not work > >>=20 >=20 > I updated python_requirements.txt to include sh - thanks for that. >=20 > >> The idea is nice, unfortunately its inflexible and it has hard-referen= ces to reference policy all-over. It has potential but it is still rough. > >=20 > >=20 > > Turns out that Fedora provides all the dependencies (some just have dif= ferent names) > >=20 > > I have created a Fedora SPAN.spec: > >=20 > > https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec > >=20 > >=20 >=20 > Thanks for making the Fedora SPEC.=20 >=20 > I know it=E2=80=99s a topic of great debate, but there are some nice thin= gs about just sticking with the Python tools for dependency management for = upstream. Mainly because it=E2=80=99s portable and helps get the latest ver= sions (which is nice for fast moving projects like Jupyter notebook and Pan= das). 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 op= tion. Its nice for simple python modules but python programs such as notebo= ok need permissions that i do not associate will login users shells, and i = dont support confining applications installed to $HOME. notebook needs perm= issions like execmem, needs network connectivity and a few other things tha= t i do not allow my user login shells. So I have to make this work system-w= ide and I wanted the benefit of being able to manage/keep track off what i = install system-wide >=20 > Karl >=20 >=20 > >>=20 > >>>=20 > >>>>=20 > >>>> --=20 > >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B= 02 > >>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C= 7B6B02 > >>>> Dominick Grift > >>>=20 > >>>=20 > >>>=20 > >>> --=20 > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > >>> Dominick Grift > >>=20 > >>=20 > >>=20 > >> --=20 > >> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B= 6B02 > >> Dominick Grift > >=20 > >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --FCuugMFkClbJLl1L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQx8AACgkQJXSOVTf5 R2lzZQv+LTtgmoFK5I11LY8HEO7Vu8YiZMLlqmx1i0i2GH8WnSGFYsK7JkuZNXQg E8P6Fo9b5aAlJhhDeRzZSekXqUvwTJYNVZiDiGykd1jVMUthHv4vZz23rZMnoRvr Vr6O5QnnoiJWcwPtVVCHFsei0XwPBjduG/1ZhPcixXNnUIMxbNpVuuY97JNKxXGt 4BIfolAx0WeZCJdUGeja6dc390h0q69nEVZjfJy6UVkFevdIevNKNO/TDvIwH3KP 9uyDr5GojISlHD5LID+J2oAb87fc7MSu5G8buhu0ys4Issd5f25dwhmoaHTPK+YY B9Z017vAz23Oot0nN0hYNANyuiQ39gAniV+Mh4XPOND9puCVWvb4+ZiuEbcsHFZS SNal9aF7WnD1FZUxR7BEIU5uXrU34vDd0RppzOxJ6yRZ+DZ32Ry8a6DzrTvoGeTf ANrQnx3BiXl5YAP+fhgiXKK+RpkbO8xpBfiK2YVhzRCkIMHXujrv4uguQgnHpkP5 p2ed5kOn =OEQh -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48JaQDC025668 for ; Mon, 8 May 2017 15:36:26 -0400 Received: by mail-qt0-f170.google.com with SMTP id m91so58802065qte.3 for ; Mon, 08 May 2017 12:36:24 -0700 (PDT) From: Karl MacMillan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BA47C1C6-D30A-4668-BC9B-813F3298A8C0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Mon, 8 May 2017 15:36:21 -0400 In-Reply-To: <20170508093229.GB3701@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_BA47C1C6-D30A-4668-BC9B-813F3298A8C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2017, at 5:32 AM, Dominick Grift = wrote: >=20 > 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: >>>>> >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> What do you mean? that for example that hard-coded array of = "trusted" types. Is that not just redundant. >>>>=20 >>>=20 >>> you mean the example trusted types? I'm not sure I understand your = concern. >>>=20 >>>> 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. >>>>=20 >>>=20 >>> 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. >>>=20 >>> I've thought about trying this on an Android policy but haven't made = it a >>> priority. >>>=20 >>>> 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? >>>=20 >>>=20 >>=20 >> ahh.. sorry. I just noticed that it can be overriden: >>=20 >> p, ps, bp, bps =3D = se.load_policies_from_config("policy_paths.config") >>=20 >> so i suppose i should be able to add that file to the notebook dir = and specify my own paths. >>=20 >> although that still doesnt deal with any file suffixes? (.cil) >=20 >=20 > take for example: = https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331 = >=20 > "domain" is a reference policy type attribute >=20 > 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) >=20 > So that the variables can we adjusted without the need to = reinstall/recompile a modified SPAN >=20 > Or just rename to RPAN (reference policy analysis notebook) I think it=E2=80=99s 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=E2=80=99ll 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=E2=80=99s the great advantage of = this versus other analysis tools. It=E2=80=99s 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 >=20 >>=20 >> --=20 >> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= = >> Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B= 02 = > Dominick Grift --Apple-Mail=_BA47C1C6-D30A-4668-BC9B-813F3298A8C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 =3D 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)

I think = it=E2=80=99s 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=E2=80=99ll 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=E2=80=99s the great advantage of this versus other analysis = tools. It=E2=80=99s 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 =3D 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B = 6B02
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3= B6C5F1D2C7B6B02
Dominick Grift



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

= --Apple-Mail=_BA47C1C6-D30A-4668-BC9B-813F3298A8C0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48Je4FC027161 for ; Mon, 8 May 2017 15:40:07 -0400 Received: by mail-qk0-f172.google.com with SMTP id y201so28950419qka.0 for ; Mon, 08 May 2017 12:40:06 -0700 (PDT) From: Karl MacMillan Message-Id: <918A6F86-3082-4755-84D9-E9C87D9E4F97@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_48A7D293-1423-4591-B16D-1B465351208D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Mon, 8 May 2017 15:40:04 -0400 In-Reply-To: <20170508193220.GA7367@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <20170507093921.GA22381@julius> <9CD79E56-C6FE-44F8-B81B-1155356E0874@gmail.com> <20170508193220.GA7367@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_48A7D293-1423-4591-B16D-1B465351208D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2017, at 3:32 PM, Dominick Grift = wrote: >=20 > On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote: >>>=20 >>=20 >> Thanks for making the Fedora SPEC.=20 >>=20 >> I know it=E2=80=99s 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=E2=80=99s portable and helps = get the latest versions (which is nice for fast moving projects like = Jupyter notebook and Pandas). >=20 > 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 >=20 Interesting. I=E2=80=99ll just note that it=E2=80=99s 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=E2=80=99s not so locked down. Karl >>=20 >> Karl >>=20 >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>>>>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= >>>>>> Dominick Grift >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>>>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= >>>>> Dominick Grift >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= = >>>> Dominick Grift >>>=20 >>>=20 >>>=20 >>> --=20 >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= = = > >>> Dominick Grift >>=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B= 02 = > Dominick Grift --Apple-Mail=_48A7D293-1423-4591-B16D-1B465351208D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99s 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=E2=80=99s = 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=E2=80=99ll just note that it=E2=80=99s 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=E2=80=99s not so locked down.

Karl


Karl





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



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



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



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


-- 
Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 =  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3= B6C5F1D2C7B6B02
Dominick = Grift
= --Apple-Mail=_48A7D293-1423-4591-B16D-1B465351208D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48Jg2rS027731 for ; Mon, 8 May 2017 15:42:02 -0400 Received: by mail-qk0-f178.google.com with SMTP id u75so61404465qka.3 for ; Mon, 08 May 2017 12:42:00 -0700 (PDT) From: Karl MacMillan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BADE1643-8300-416F-B392-6762F3D47C72" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Mon, 8 May 2017 15:41:58 -0400 In-Reply-To: <20170507195338.GC31890@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170507195338.GC31890@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_BADE1643-8300-416F-B392-6762F3D47C72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 7, 2017, at 3:53 PM, Dominick Grift = wrote: >=20 >=20 > Python is not really my thing so i will have to get used to it and = explore my options >=20 > Its a cool module, has a few rough edges (but thats to be expected = from v0.0.0) >=20 So far I=E2=80=99ve seen your concerns over installation and reference = policy assumptions. Any other =E2=80=9Crough edges=E2=80=9D that = you=E2=80=99ve 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? >>=20 >>=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B= 02 = > Dominick Grift --Apple-Mail=_BADE1643-8300-416F-B392-6762F3D47C72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99ve seen your concerns over installation and reference policy = assumptions. Any other =E2=80=9Crough edges=E2=80=9D that you=E2=80=99ve = 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 =3D 5F4D 3CDB D3F8 3652 FBD8 =  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3= B6C5F1D2C7B6B02
Dominick = Grift

= --Apple-Mail=_BADE1643-8300-416F-B392-6762F3D47C72-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48JnaqF029742 for ; Mon, 8 May 2017 15:49:36 -0400 Received: by mail-wm0-f50.google.com with SMTP id u65so96937876wmu.1 for ; Mon, 08 May 2017 12:49:34 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id g24sm4039679edh.20.2017.05.08.12.49.32 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 12:49:32 -0700 (PDT) Date: Mon, 8 May 2017 21:49:31 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508194931.GB7367@julius> References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" In-Reply-To: List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: >=20 > > On May 8, 2017, at 5:32 AM, Dominick Grift wro= te: > >=20 > > 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: > >>>>> > >>>>>=20 > >>>>>> The idea is nice, unfortunately its inflexible and it has hard-ref= erences to reference policy all-over. It has potential but it is still roug= h. > >>>>>>=20 > >>>>> Of course, it is an analysis of a refpolicy-based policy. If you wa= nt to > >>>>> analyze a different policy (e.g., Android or home-rolled) you will = have to > >>>>> change out all of the type sets, etc. > >>>>>=20 > >>>>> 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 compone= nts. > >>>>=20 > >>>> What do you mean? that for example that hard-coded array of "trusted= " types. Is that not just redundant. > >>>>=20 > >>>=20 > >>> you mean the example trusted types? I'm not sure I understand your co= ncern. > >>>=20 > >>>> Can't i just create that array myself and use it to exlude rules wit= h types in that array? That was one does not have to hard-code it. > >>>>=20 > >>>=20 > >>> It is python, you can do anything you want. The example notebook is a > >>> starting point, anyone doing an analysis would probably make major ch= anges > >>> for their analysis, which is the point. You modify the notebook to bu= ild a > >>> usable analysis between the starting policy and the policy you are > >>> analyzing. > >>>=20 > >>> I've thought about trying this on an Android policy but haven't made = it a > >>> priority. > >>>=20 > >>>> Also with regard to hardcoding the refpolicy file system (ps.load_po= licy_source). I mean if youre just going to `grep -r` then why do we have t= o assume anything there and hard code file suffixed, directory structures e= tc etc? > >>>=20 > >>>=20 > >>=20 > >> ahh.. sorry. I just noticed that it can be overriden: > >>=20 > >> p, ps, bp, bps =3D se.load_policies_from_config("policy_paths.config") > >>=20 > >> so i suppose i should be able to add that file to the notebook dir and= specify my own paths. > >>=20 > >> although that still doesnt deal with any file suffixes? (.cil) > >=20 > >=20 > > take for example: https://github.com/QuarkSecurity/SPAN/blob/master/spa= n/span.py#L331 > >=20 > > "domain" is a reference policy type attribute > >=20 > > One should expand on the "policy_paths.config" concept and allow us, vi= a configuration files, to override all the variables (attributes, suffixes,= paths, identifiers, etc) > >=20 > > So that the variables can we adjusted without the need to reinstall/rec= ompile a modified SPAN > >=20 > > Or just rename to RPAN (reference policy analysis notebook) >=20 > I think it=E2=80=99s best to think of these as having three basic layers: >=20 > 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, att= ributes, 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. >=20 > 2. Higher-level policy analysis methods - these are things like the domai= n_types method and the domain / type summaries. These make some minimal ass= umptions about attributes like domain. I=E2=80=99ll just mention that these= assumptions are very minimal and have been around for a _long_ time. Domai= n long pre-dates the reference policy, for example. More than attributes th= is layer is tied to the Linux object classes and permissions. >=20 > 3. Example notebooks - the two example notebooks are just that - examples= =2E They probably provide a useful starting point, but as Josh points out, = should simply be modified for your specific use case. >=20 > So the question, then, is should the second layer (the higher-level polic= y 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 ass= umptions. To me, that=E2=80=99s the great advantage of this versus other an= alysis tools. It=E2=80=99s so simple to create quick tools that meet your n= eeds. And given that the vast majority of Linux and Android systems meet th= e 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= =2E for example the source functionality appends "modules" to the search pa= th. 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 t= he notebook and its depenedencies are pretty expensive to have just for som= ething that only works to some extent. Atleast this inspired me to implement policy for pip and notebook in my per= sonal security policy. So it was not all in vain. >=20 > Thanks - Karl >=20 > >=20 > >>=20 > >> --=20 > >> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B= 6B02 > >> Dominick Grift > >=20 > >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQy8YACgkQJXSOVTf5 R2mfFAwAgcZpZQe0po9WxDdwq63vVbGIVpmqP2odRPAVIX1CmPevRfyBA/qomIh0 MlfYf9nmI27omcz4Oz65O7Jm0BPiUuJ817LovKHixcW+i4FCT//A87OjrLsKKAsC AXvl6Cr11EGne7IqbERysm459lnGwI50Wai/LGFx8ZkxLZU+BN44IGgz5rWfqZoy dFsiKV8C3NodKHQvtMpMCY7rQTmcNUvZxzivoXZVjxZHE0swT+kODgCxoi1YS91X QR/SG4rSHLSYx9bYyKTc8K5yPGAKNC70qfPLn0I9XadSpFakrgtwGJyvSDahmvqE tAszxRQkRD8RsnSqYizXh7cxZQesUco/nhr1YRLCr7yyzmTzOzlys6v2BDqoPEwJ 6afgtm9ZSa/rokxmcG+ixDrG+j23uvBXYhie3D7HlbBdNTwVQ/CPctxQEa9UfcWx /zVwyzz03YtEB66P4vWU9jiQm0BwRW7kmYKdldclwvaSGlybtWHWo/Ci4cTagD0+ EaOIdvMr =CnZR -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48K9K65004764 for ; Mon, 8 May 2017 16:09:20 -0400 Received: by mail-qk0-f181.google.com with SMTP id a72so45998885qkj.2 for ; Mon, 08 May 2017 13:09:18 -0700 (PDT) From: Karl MacMillan Message-Id: <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1464EA85-F308-4313-BE14-30C11ECD8239" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Mon, 8 May 2017 16:09:16 -0400 In-Reply-To: <20170508194931.GB7367@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506140358.GA21008@julius> <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_1464EA85-F308-4313-BE14-30C11ECD8239 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2017, at 3:49 PM, Dominick Grift = wrote: >=20 > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: >>=20 >>>=20 >>=20 >> I think it=E2=80=99s best to think of these as having three basic = layers: >>=20 >> 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. >>=20 >> 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=E2=80=99ll 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. >>=20 >> 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. >>=20 >> 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=E2=80=99s the great advantage of = this versus other analysis tools. It=E2=80=99s 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. >=20 > 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=E2=80=99ve not tested it for Android policies so I=E2=80=99m 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=E2=80=99m not certain what you mean and was not = trying to say something about you personally. I was not familiar with DSSP before (I=E2=80=99ve not done much with = SELinux for a while), but Josh pointed it out to me. =46rom 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=E2=80=99s nice to see someone trying to write a = policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D = 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=E2=80=99m curious what you mean by =E2=80=9Conly works to some = extent=E2=80=9D. 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=E2=80=99ll 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. >=20 >>=20 >> Thanks - Karl >>=20 >>>=20 >>>>=20 >>>> --=20 >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= = = > >>>> Dominick Grift >>>=20 >>>=20 >>>=20 >>> --=20 >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 >>> = https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02= = = > >>> Dominick Grift >>=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B= 02 = > Dominick Grift --Apple-Mail=_1464EA85-F308-4313-BE14-30C11ECD8239 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99s 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=E2=80=99ll 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=E2=80=99s the great advantage of this versus other analysis tools. = It=E2=80=99s 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=E2=80=99ve= not tested it for Android policies so I=E2=80=99m 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=E2=80=99m not certain what you = mean and was not trying to say something about you = personally.

I was not familiar with = DSSP before (I=E2=80=99ve not done much with SELinux for a while), but = Josh pointed it out to me. =46rom 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=E2=80=99s nice to see someone trying to write a policy from = scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D 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=E2=80=99m = curious what you mean by =E2=80=9Conly works to some extent=E2=80=9D. = 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=E2=80=99ll 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 =3D 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B = 6B02
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3= B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3= B6C5F1D2C7B6B02>
Dominick Grift



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


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

= --Apple-Mail=_1464EA85-F308-4313-BE14-30C11ECD8239-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48Kf0d6015090 for ; Mon, 8 May 2017 16:41:00 -0400 Received: by mail-wm0-f54.google.com with SMTP id m123so78138201wma.0 for ; Mon, 08 May 2017 13:40:57 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id w44sm2465999edd.53.2017.05.08.13.40.54 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 13:40:55 -0700 (PDT) Date: Mon, 8 May 2017 22:40:53 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508204053.GC7367@julius> References: <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" In-Reply-To: <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: >=20 > > On May 8, 2017, at 3:49 PM, Dominick Grift wro= te: > >=20 > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > >>=20 > >>>=20 > >>=20 > >> I think it=E2=80=99s best to think of these as having three basic laye= rs: > >>=20 > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usab= le for any policy and make no assumptions about the presence of any types, = attributes, object classes, or permissions. So things like the rule searchi= ng and information flow analysis fit into this group. This is a large part = of the value of SPAN. > >>=20 > >> 2. Higher-level policy analysis methods - these are things like the do= main_types method and the domain / type summaries. These make some minimal = assumptions about attributes like domain. I=E2=80=99ll just mention that th= ese assumptions are very minimal and have been around for a _long_ time. Do= main long pre-dates the reference policy, for example. More than attributes= this layer is tied to the Linux object classes and permissions. > >>=20 > >> 3. Example notebooks - the two example notebooks are just that - examp= les. They probably provide a useful starting point, but as Josh points out,= should simply be modified for your specific use case. > >>=20 > >> So the question, then, is should the second layer (the higher-level po= licy analysis methods) be made configurable. Honestly I think it would be m= ore work than just creating your own versions for a policy that breaks the = assumptions. To me, that=E2=80=99s the great advantage of this versus other= analysis tools. It=E2=80=99s so simple to create quick tools that meet you= r needs. And given that the vast majority of Linux and Android systems meet= the assumptions I think that this is a reasonable approach. > >=20 > > I don't think it will work with android. Some of it maybe but not all o= f it. for example the source functionality appends "modules" to the search = path. So i suspect that will break that functionality for Android. >=20 > We=E2=80=99ve not tested it for Android policies so I=E2=80=99m sure ther= e will be some breakage. But I hope it will be fixed to work by us or someo= ne soon. >=20 > > Thank you for giving me your opinion. At least now I know where I stand. >=20 > Where you stand? I=E2=80=99m 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). = =46rom your comments I sensed that you might not fully agree with that or t= hat 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) >=20 > I was not familiar with DSSP before (I=E2=80=99ve not done much with SELi= nux for a while), but Josh pointed it out to me. From looking at it very br= iefly and thinking through the assumptions in SPAN my guess is that it woul= d 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 diffin= g constraints). >=20 > And as a side note - it=E2=80=99s nice to see someone trying to write a p= olicy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D 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 =3D domain Then i would be happy because then i could edit it like: process_types =3D subj.subj_type_attribute >=20 > > 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 f= or something that only works to some extent. >=20 > I=E2=80=99m curious what you mean by =E2=80=9Conly works to some extent= =E2=80=9D. 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 ass= umptions I think that this is a reasonable approach." >=20 > And if you mean specifically in the context of DSSP, like I said I bet th= e changes would be minimal. So if you are interested in giving it a try I= =E2=80=99ll 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 u= sable 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 suff= ixed 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 con= text specs in the .cil suffixed file 4.=20 return self.diff_relative("/policy/mls", other_source) # these should be cu= stomizable return self.diff_relative("/policy/mcs", other_source) # these should be cu= stomizable return self.diff_relative("/policy/constraints", other_source) # these shou= ld be customizable 5. any references to type attributes should be customizable: ie. process_ty= pes =3D ... filesystem_types =3D ... etc >=20 > Thanks - Karl >=20 > > Atleast this inspired me to implement policy for pip and notebook in my= personal security policy. So it was not all in vain. > >=20 > >>=20 > >> Thanks - Karl > >>=20 > >>>=20 > >>>>=20 > >>>> --=20 > >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B= 02 > >>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C= 7B6B02 > > >>>> Dominick Grift > >>>=20 > >>>=20 > >>>=20 > >>> --=20 > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > > >>> Dominick Grift > >>=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQ19EACgkQJXSOVTf5 R2nRbQv+PepFIDDKoWcLt6JW4XsXIK1RCV2+5o80It8QZ20WtPhCh8duSdDr6DBn 3FOy9of9WRmrIynMRgLn5ao69+Dt9yiBqU8go616pGFckm/DO8wVnjF5cx0Dkj+C Kv73uiexQAouIWd+6CYrCkq4KG0jG6Y6NTU18ZhtIj7rTtwD8zGIbe/DD7J/Q10e 3H+K9XvtirstqyrTwW29YiXAn0oENFHBWQc6j5C2cNeiXbHCwgs/g69qT4ZAJqiJ xZrEd15HgO/nhmF2M5aqRjVBVHVmzlQ5FsVMnOxnuR93apquhWw4Y/7aWGtUfonj Y6ekykV0OudFx5nAe/LNY0/i8yab6u303c1BuEg8T5YvhLT20inHFL5RAQawgAkq d7mbLqK0Y4oyAUY1Aeth/fzg5ph/xciqvsNAGzwr1/pH1OzMSwiOjdzcbiLgj9UG vk8NwwzGMPndKHZSkRb3zgA7WsfhInShmFX1sGIUiI1/JL5WdMcv6l18juRKW32G Maqf86eS =nGAT -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48LlKO9003734 for ; Mon, 8 May 2017 17:47:20 -0400 Received: by mail-wm0-f42.google.com with SMTP id 142so80183020wma.1 for ; Mon, 08 May 2017 14:47:18 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id a56sm4744540eda.3.2017.05.08.14.47.15 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 14:47:15 -0700 (PDT) Date: Mon, 8 May 2017 23:47:14 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508214714.GD7367@julius> References: <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SFyWQ0h3ruR435lw" In-Reply-To: <20170508204053.GC7367@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --SFyWQ0h3ruR435lw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > On May 8, 2017, at 3:49 PM, Dominick Grift w= rote: > > >=20 > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > >>=20 > > >>>=20 > > >>=20 > > >> I think it=E2=80=99s best to think of these as having three basic la= yers: > > >>=20 > > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are us= able for any policy and make no assumptions about the presence of any types= , attributes, object classes, or permissions. So things like the rule searc= hing and information flow analysis fit into this group. This is a large par= t of the value of SPAN. > > >>=20 > > >> 2. Higher-level policy analysis methods - these are things like the = domain_types method and the domain / type summaries. These make some minima= l assumptions about attributes like domain. I=E2=80=99ll 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 attribut= es this layer is tied to the Linux object classes and permissions. > > >>=20 > > >> 3. Example notebooks - the two example notebooks are just that - exa= mples. They probably provide a useful starting point, but as Josh points ou= t, should simply be modified for your specific use case. > > >>=20 > > >> 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 th= e assumptions. To me, that=E2=80=99s the great advantage of this versus oth= er analysis tools. It=E2=80=99s so simple to create quick tools that meet y= our needs. And given that the vast majority of Linux and Android systems me= et the assumptions I think that this is a reasonable approach. > > >=20 > > > 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 searc= h path. So i suspect that will break that functionality for Android. > >=20 > > We=E2=80=99ve not tested it for Android policies so I=E2=80=99m sure th= ere will be some breakage. But I hope it will be fixed to work by us or som= eone soon. > >=20 > > > Thank you for giving me your opinion. At least now I know where I sta= nd. > >=20 > > Where you stand? I=E2=80=99m not certain what you mean and was not tryi= ng to say something about you personally. >=20 > I didnt take it personal, That is not what I meant. To me SELinux is bigg= er then any single policy be it refpolicy, sepolicy, or dssp > The perfect tool would support any policy (setools goes a long way there)= =2E 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 illusion= s that SPAN will ever be perfect (or close to perfect) >=20 > >=20 > > I was not familiar with DSSP before (I=E2=80=99ve not done much with SE= Linux 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 wo= uld take very few changes to make SPAN work with DSSP, even the source poli= cy stuff (which, honestly, is just a very small part mainly useful for diff= ing constraints). > >=20 > > And as a side note - it=E2=80=99s nice to see someone trying to write a= policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D attribu= te or at least a similar concept? >=20 > Sure, but i cannot use "domain" for this because DSSP leverages namespace= s. The equivalent in DSSP is "subj.subj_type_attribute" >=20 > So if the configuration file would have something like: >=20 > # process_types =3D domain >=20 > Then i would be happy because then i could edit it like: >=20 > process_types =3D subj.subj_type_attribute >=20 > >=20 > > > I will not be able to leverage this solution to any significant exten= d, and the notebook and its depenedencies are pretty expensive to have just= for something that only works to some extent. > >=20 > > I=E2=80=99m curious what you mean by =E2=80=9Conly works to some extent= =E2=80=9D. Any bug reports would be welcome. >=20 > Let me rephrase then: "not to the fullest extent" >=20 > 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 a= ssumptions I think that this is a reasonable approach." >=20 > >=20 > > 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= =E2=80=99ll be happy to look at the changes needed and give you a hand. >=20 > 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 assumptio= ns: >=20 > ill point out some: >=20 > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil su= ffixed files? We should make this customizable something like: source_policy_suffix =3D Because we would need to catch *.conf , *.te , *.cil and any future high le= vel source policy files that leverage cil > 2. return self.find_def("attribute " + name) # in CIL this is typeattribu= te CIL is a native language so we use a statement for something then we need t= o make sure that also its CIL equivalent is caught > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its c= ontext specs in the .cil suffixed file We should make this customizable: file_contexts_suffix =3D to catch *.fc as well as *.cil and any future high level file_context suffi= xes When this suffix is used we should also alway take "file_contexts" into acc= ount as this is where to look in monolitic policy > 4.=20 > return self.diff_relative("/policy/mls", other_source) # these should be = customizable mls_constraints =3D > return self.diff_relative("/policy/mcs", other_source) # these should be = customizable mcs_constraints =3D > return self.diff_relative("/policy/constraints", other_source) # these sh= ould be customizable constraints =3D or maybe dont even differentiate between the various different constraints = and just pile them all together in: constraints =3D [ "", "", "", ... ] This is because there may be other constraints (for example i have role-bas= e access control seperation constraints) > 5. any references to type attributes should be customizable: ie. process_= types =3D ... filesystem_types =3D ... etc I do not consider Linux access vectors to be customizable, unlike types ,at= tributes, booleans, tunables etc) So one does not have to worry about the hard coding of classes and permissi= on, However i would probably still try to find a way make that more easily customizable. Because new permissions get added to ex= isting classes and if you have you access vector declarations in a single p= lace then that is easier to maintain then when you have to add then in code= scathered accross the project >=20 > >=20 > > Thanks - Karl > >=20 > > > Atleast this inspired me to implement policy for pip and notebook in = my personal security policy. So it was not all in vain. > > >=20 > > >>=20 > > >> Thanks - Karl > > >>=20 > > >>>=20 > > >>>>=20 > > >>>> --=20 > > >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 > > >>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D= 2C7B6B02 > > > >>>> Dominick Grift > > >>>=20 > > >>>=20 > > >>>=20 > > >>> --=20 > > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6= B02 > > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2= C7B6B02 > > > >>> Dominick Grift > > >>=20 > > >=20 > > > --=20 > > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > > > Dominick Grift > >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --SFyWQ0h3ruR435lw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQ510ACgkQJXSOVTf5 R2mK2Qv9GYBXunIDM/XfTMC0ksa5z8jezyChOD7jmDg4vC9SjTV7hLMHdmLaXr9c Ox6BPuOvlP6lH5t9T31tZIiPKsz/0OW7/afJlFH+l4tN0AIooxTSFj3xlxj07qdo RdIQPFJrbRbi+aMHY5Mr4ZuP1LM9qHgvQzuq5jwGHVlDc+mOH46N/84SYxoI+cK1 9+8pCWgTJ/EbBnAi40IhbrMevwQa9VAp7ruIVb3AtkfrGgcXZPELL96/SK8hJYyu Tn+rSLzv+j8PzTfd4Wh4ktss59WWosVPU7vw+mLDziJgW/4ys1XQPgQun2MTWGZj 5SRrYPBpKNm5NqKKPrnbmYHpvPsJAdXZTpLgxR5eEEcmR56mENHcDiaRy6hZMW3k EgRmu2GpBd7GndeREEIkw1wZM4rkcP9HPFBOcxpDEE8Udtvq6UavrnsMxYAUdrxU hbUflyjyK5zeRFkZ5wUa7eq3IsKgnVz9RFV6RMT9wZy85KgrM5aFLhNCugFl4ipp m60oPGKQ =4f27 -----END PGP SIGNATURE----- --SFyWQ0h3ruR435lw-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v48M1Nuj009051 for ; Mon, 8 May 2017 18:01:23 -0400 Received: by mail-wm0-f50.google.com with SMTP id 142so80471080wma.1 for ; Mon, 08 May 2017 15:01:20 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id k17sm5374147eda.61.2017.05.08.15.01.18 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 15:01:18 -0700 (PDT) Date: Tue, 9 May 2017 00:01:17 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170508220117.GE7367@julius> References: <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> <20170508214714.GD7367@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hwvH6HDNit2nSK4j" In-Reply-To: <20170508214714.GD7367@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --hwvH6HDNit2nSK4j Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > >=20 > > > > On May 8, 2017, at 3:49 PM, Dominick Grift = wrote: > > > >=20 > > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > > >>=20 > > > >>>=20 > > > >>=20 > > > >> I think it=E2=80=99s best to think of these as having three basic = layers: > > > >>=20 > > > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are = usable for any policy and make no assumptions about the presence of any typ= es, attributes, object classes, or permissions. So things like the rule sea= rching and information flow analysis fit into this group. This is a large p= art of the value of SPAN. > > > >>=20 > > > >> 2. Higher-level policy analysis methods - these are things like th= e domain_types method and the domain / type summaries. These make some mini= mal assumptions about attributes like domain. I=E2=80=99ll just mention tha= t these assumptions are very minimal and have been around for a _long_ time= =2E Domain long pre-dates the reference policy, for example. More than attr= ibutes this layer is tied to the Linux object classes and permissions. > > > >>=20 > > > >> 3. Example notebooks - the two example notebooks are just that - e= xamples. They probably provide a useful starting point, but as Josh points = out, should simply be modified for your specific use case. > > > >>=20 > > > >> So the question, then, is should the second layer (the higher-leve= l 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=E2=80=99s the great advantage of this versus o= ther analysis tools. It=E2=80=99s 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. > > > >=20 > > > > I don't think it will work with android. Some of it maybe but not a= ll of it. for example the source functionality appends "modules" to the sea= rch path. So i suspect that will break that functionality for Android. > > >=20 > > > We=E2=80=99ve not tested it for Android policies so I=E2=80=99m sure = there will be some breakage. But I hope it will be fixed to work by us or s= omeone soon. > > >=20 > > > > Thank you for giving me your opinion. At least now I know where I s= tand. > > >=20 > > > Where you stand? I=E2=80=99m not certain what you mean and was not tr= ying to say something about you personally. > >=20 > > I didnt take it personal, That is not what I meant. To me SELinux is bi= gger then any single policy be it refpolicy, sepolicy, or dssp > > The perfect tool would support any policy (setools goes a long way ther= e). 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 illusi= ons that SPAN will ever be perfect (or close to perfect) > >=20 > > >=20 > > > I was not familiar with DSSP before (I=E2=80=99ve not done much with = SELinux for a while), but Josh pointed it out to me. From looking at it ver= y 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 po= licy stuff (which, honestly, is just a very small part mainly useful for di= ffing constraints). > > >=20 > > > And as a side note - it=E2=80=99s nice to see someone trying to write= a policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D attri= bute or at least a similar concept? > >=20 > > Sure, but i cannot use "domain" for this because DSSP leverages namespa= ces. The equivalent in DSSP is "subj.subj_type_attribute" > >=20 > > So if the configuration file would have something like: > >=20 > > # process_types =3D domain > >=20 > > Then i would be happy because then i could edit it like: > >=20 > > process_types =3D subj.subj_type_attribute > >=20 > > >=20 > > > > I will not be able to leverage this solution to any significant ext= end, and the notebook and its depenedencies are pretty expensive to have ju= st for something that only works to some extent. > > >=20 > > > I=E2=80=99m curious what you mean by =E2=80=9Conly works to some exte= nt=E2=80=9D. Any bug reports would be welcome. > >=20 > > Let me rephrase then: "not to the fullest extent" > >=20 > > But you gave me the impression that not all bug reports would be "welco= me" when you said: "the vast majority of Linux and Android systems meet the= assumptions I think that this is a reasonable approach." > >=20 > > >=20 > > > And if you mean specifically in the context of DSSP, like I said I be= t the changes would be minimal. So if you are interested in giving it a try= I=E2=80=99ll be happy to look at the changes needed and give you a hand. > >=20 > > I agree, and ive said that when I said: "a few rough edges" Its close t= he usable with DSSP. It just needs to deal with some of the current assumpt= ions: > >=20 > > ill point out some: > >=20 > > 1. return self.grep(name, "*.te", self.modules_path) # what about .cil = suffixed files? >=20 > We should make this customizable something like: source_policy_suffix =3D >=20 > Because we would need to catch *.conf , *.te , *.cil and any future high = level source policy files that leverage cil >=20 > > 2. return self.find_def("attribute " + name) # in CIL this is typeattri= bute >=20 > 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 >=20 > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its= context specs in the .cil suffixed file >=20 > We should make this customizable: file_contexts_suffix =3D > to catch *.fc as well as *.cil and any future high level file_context suf= fixes > When this suffix is used we should also alway take "file_contexts" into a= ccount as this is where to look in monolitic policy >=20 > > 4.=20 > > return self.diff_relative("/policy/mls", other_source) # these should b= e customizable >=20 > mls_constraints =3D >=20 > > return self.diff_relative("/policy/mcs", other_source) # these should b= e customizable >=20 > mcs_constraints =3D >=20 > > return self.diff_relative("/policy/constraints", other_source) # these = should be customizable >=20 > constraints =3D >=20 > or maybe dont even differentiate between the various different constraint= s and just pile them all together in: >=20 > constraints =3D [ "", "", "", ... ] As a matter of fact, constraints could be anywhere. So probably better to f= ind a different way to get all the constraints in cil you can have your constraints whereever you want. For example : I ha= ve 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 pol= icy on top of CIL it was a limitation of module policy that we couldnt have constraints in mo= dules in the past >=20 > This is because there may be other constraints (for example i have role-b= ase access control seperation constraints) >=20 > > 5. any references to type attributes should be customizable: ie. proces= s_types =3D ... filesystem_types =3D ... etc >=20 > I do not consider Linux access vectors to be customizable, unlike types ,= attributes, booleans, tunables etc) >=20 > So one does not have to worry about the hard coding of classes and permis= sion, 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 co= de scathered accross the project >=20 > >=20 > > >=20 > > > Thanks - Karl > > >=20 > > > > Atleast this inspired me to implement policy for pip and notebook i= n my personal security policy. So it was not all in vain. > > > >=20 > > > >>=20 > > > >> Thanks - Karl > > > >>=20 > > > >>>=20 > > > >>>>=20 > > > >>>> --=20 > > > >>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7= B 6B02 > > > >>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F= 1D2C7B6B02 > > > > >>>> Dominick Grift > > > >>>=20 > > > >>>=20 > > > >>>=20 > > > >>> --=20 > > > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B= 6B02 > > > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1= D2C7B6B02 > > > > >>> Dominick Grift > > > >>=20 > > > >=20 > > > > --=20 > > > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6= B02 > > > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2= C7B6B02 > > > > Dominick Grift > > >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --hwvH6HDNit2nSK4j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkQ6qkACgkQJXSOVTf5 R2mU2gv9HkkTQcMMlmLNyCz9CF2qpT/oM1b+GQvF8MZVAj0sF3lqUmMM5AJbH7Rr NgZhAwecsiGr02LVwKna16DvtRje4ijlWvW2JMhIpsA/+uAg8ABTKGMBJyDLw8jL jhjRoVEwmqEdSirKCnuQD8eKXvxSa+vAMAywocDpz0OTMtB2n+H/IqmHFE46k9rb VNZuMsfJ2N8Y9xNnfLG/lgCGVDDEUSoHrE//QxavpOsBFck/cXjfge/ezErO53pK qdOWw5mJf0c0ble6WohgONtE2qZKnkEiT0bxgICCN+qg1DH+7d2r3+/VloZ0yGKS bxLMj+73bJGcuslLbctzHgTtQqT3OgifsfD9I20NzqJKsfg1Md7WMnJEtCxmTKwR 8Z3HrJ4XBLPvLp1qcFtJUtkf8Tb7i7rd3zPEtZ0Juz6SOgXR+K7cG2rr/zteq+S9 vNQq+fYqGynvmHamArLva8ZGJST4L2cOCauGbxqKStd8QQhUi/HuQ2Jygt2vvRRQ 1xVZ4lfZ =U8bt -----END PGP SIGNATURE----- --hwvH6HDNit2nSK4j-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49FLmup014274 for ; Tue, 9 May 2017 11:21:49 -0400 Received: by mail-qt0-f177.google.com with SMTP id n4so3609950qte.2 for ; Tue, 09 May 2017 08:21:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook From: Karl MacMillan In-Reply-To: <20170508204053.GC7367@julius> Date: Tue, 9 May 2017 11:21:23 -0400 Cc: selinux@tycho.nsa.gov Message-Id: References: <20170506161956.GA20145@julius> <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> To: Dominick Grift List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: > On May 8, 2017, at 4:40 PM, 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 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 > >>>>>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49FPm7E015981 for ; Tue, 9 May 2017 11:25:48 -0400 Received: by mail-qt0-f178.google.com with SMTP id n4so3728416qte.2 for ; Tue, 09 May 2017 08:25:46 -0700 (PDT) From: Karl MacMillan Message-Id: <84F6F2D5-393C-4313-A88D-02E596729B8A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80D3D97B-6538-446C-B32C-11421B9F6EAB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Date: Tue, 9 May 2017 11:25:44 -0400 In-Reply-To: <20170508214714.GD7367@julius> Cc: selinux@tycho.nsa.gov To: Dominick Grift References: <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> <20170508214714.GD7367@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --Apple-Mail=_80D3D97B-6538-446C-B32C-11421B9F6EAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2017, at 5:47 PM, Dominick Grift = wrote: >=20 > 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: >>>=20 >>>> On May 8, 2017, at 3:49 PM, Dominick Grift = wrote: >>>>=20 >>=20 >>>=20 >>> 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=E2=80=99ll be happy to look at the changes needed and give you a = hand. >>=20 >> 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: >>=20 >> ill point out some: >>=20 >> 1. return self.grep(name, "*.te", self.modules_path) # what about = .cil suffixed files? >=20 > We should make this customizable something like: source_policy_suffix = =3D >=20 > Because we would need to catch *.conf , *.te , *.cil and any future = high level source policy files that leverage cil >=20 Like I said, I just renamed the PolicySource object to reflect that = it=E2=80=99s 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] >=20 >> 5. any references to type attributes should be customizable: ie. = process_types =3D ... filesystem_types =3D ... etc >=20 > I do not consider Linux access vectors to be customizable, unlike = types ,attributes, booleans, tunables etc) >=20 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.=20 Thanks - Karl --Apple-Mail=_80D3D97B-6538-446C-B32C-11421B9F6EAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99ll 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 =3D

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=E2=80=99s = 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 =3D ... filesystem_types =3D ... 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


= --Apple-Mail=_80D3D97B-6538-446C-B32C-11421B9F6EAB-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49GD3Xt001465 for ; Tue, 9 May 2017 12:13:05 -0400 Received: by mail-qk0-f177.google.com with SMTP id a72so5183366qkj.2 for ; Tue, 09 May 2017 09:13:00 -0700 (PDT) Message-ID: <5911EA89.2060504@quarksecurity.com> Date: Tue, 09 May 2017 12:12:57 -0400 From: Joshua Brindle MIME-Version: 1.0 To: Karl MacMillan CC: Dominick Grift , selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook References: <20170506171920.GB20145@julius> <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> <20170508214714.GD7367@julius> <84F6F2D5-393C-4313-A88D-02E596729B8A@gmail.com> In-Reply-To: <84F6F2D5-393C-4313-A88D-02E596729B8A@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: Karl MacMillan wrote: > >>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49GFw4f002180 for ; Tue, 9 May 2017 12:15:58 -0400 Received: by mail-lf0-f46.google.com with SMTP id 99so4943841lfu.1 for ; Tue, 09 May 2017 09:15:47 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id b3sm447469ede.9.2017.05.09.09.15.44 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 May 2017 09:15:44 -0700 (PDT) Date: Tue, 9 May 2017 18:15:43 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170509161543.GA13560@julius> References: <590F3B98.406@quarksecurity.com> <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" In-Reply-To: List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote: >=20 > > On May 8, 2017, at 4:40 PM, Dominick Grift wro= te: > >=20 > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > >>=20 > >>> On May 8, 2017, at 3:49 PM, Dominick Grift w= rote: > >>>=20 > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > >>>>=20 > >>>>>=20 > >>>>=20 > >>>> I think it=E2=80=99s best to think of these as having three basic la= yers: > >>>>=20 > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are us= able for any policy and make no assumptions about the presence of any types= , attributes, object classes, or permissions. So things like the rule searc= hing and information flow analysis fit into this group. This is a large par= t of the value of SPAN. > >>>>=20 > >>>> 2. Higher-level policy analysis methods - these are things like the = domain_types method and the domain / type summaries. These make some minima= l assumptions about attributes like domain. I=E2=80=99ll 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 attribut= es this layer is tied to the Linux object classes and permissions. > >>>>=20 > >>>> 3. Example notebooks - the two example notebooks are just that - exa= mples. They probably provide a useful starting point, but as Josh points ou= t, should simply be modified for your specific use case. > >>>>=20 > >>>> 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 th= e assumptions. To me, that=E2=80=99s the great advantage of this versus oth= er analysis tools. It=E2=80=99s so simple to create quick tools that meet y= our needs. And given that the vast majority of Linux and Android systems me= et the assumptions I think that this is a reasonable approach. > >>>=20 > >>> 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 searc= h path. So i suspect that will break that functionality for Android. > >>=20 > >> We=E2=80=99ve not tested it for Android policies so I=E2=80=99m sure t= here will be some breakage. But I hope it will be fixed to work by us or so= meone soon. > >>=20 > >>> Thank you for giving me your opinion. At least now I know where I sta= nd. > >>=20 > >> Where you stand? I=E2=80=99m not certain what you mean and was not try= ing to say something about you personally. > >=20 > > I didnt take it personal, That is not what I meant. To me SELinux is bi= gger then any single policy be it refpolicy, sepolicy, or dssp > > The perfect tool would support any policy (setools goes a long way ther= e). 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 illusi= ons that SPAN will ever be perfect (or close to perfect) > >=20 >=20 > Shrug. SELinux is =E2=80=9Cbigger=E2=80=9D 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, bu= t too much abstraction interferes with getting work done clearly. >=20 > Ultimately SPAN has to make some assumptions about how policy works to do= any higher-level analysis (a problem that SETools doesn=E2=80=99t really h= ave because it doesn=E2=80=99t do much of the higher-level analysis that I= =E2=80=99m talking about). Making that somewhat configurable is fine, but n= ot at the cost of comprehensibility. When we hit that point it=E2=80=99s be= tter just to split the higher-level analysis methods into different version= s based the policy type. >=20 > Either way, I=E2=80=99m open to including the customizations or separate = code in SPAN. >=20 > >>=20 > >> I was not familiar with DSSP before (I=E2=80=99ve not done much with S= ELinux 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 w= ould take very few changes to make SPAN work with DSSP, even the source pol= icy stuff (which, honestly, is just a very small part mainly useful for dif= fing constraints). > >>=20 > >> And as a side note - it=E2=80=99s nice to see someone trying to write = a policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D attrib= ute or at least a similar concept? > >=20 > > Sure, but i cannot use "domain" for this because DSSP leverages namespa= ces. The equivalent in DSSP is =E2=80=9Csubj.subj_type_attribute" > >=20 >=20 > 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? >=20 > > So if the configuration file would have something like: > >=20 > > # process_types =3D domain > >=20 > > Then i would be happy because then i could edit it like: > >=20 > > process_types =3D subj.subj_type_attribute > >=20 >=20 > 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 t= his: >=20 > p =3D span.load_policy(=E2=80=9Csome_dssp_policy.cil=E2=80=9D) > p.domain_attribute =3D =E2=80=9Csubj.subj_type_attribute=E2=80=9D > p.domain_types() # This now looks for the subj.subj_type_attribute instea= d of domain Thanks! I spent all day working on my analysis of unconfined access: https://github= =2Ecom/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.ip= ynb Its not so easy: 1. first i had to get familiar with notebook and aqcuire in a such a way th= at 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 p= ython 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 anal= ysis 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 spa= n 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 meanin= g 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. >=20 > If you want to send patches for similar changes I=E2=80=99ll be happy to = review them. >=20 > Note that a configuration file is not really appropriate I don=E2=80=99t = think. This is a Python library and it=E2=80=99s better to just do the conf= iguration in code. If you have several changes that are needed for a dssp p= olicy feel free to propose a load_dssp_policy top-level function that sets = the defaults as necessary. >=20 > >>=20 > >>> I will not be able to leverage this solution to any significant exten= d, and the notebook and its depenedencies are pretty expensive to have just= for something that only works to some extent. > >>=20 > >> I=E2=80=99m curious what you mean by =E2=80=9Conly works to some exten= t=E2=80=9D. Any bug reports would be welcome. > >=20 > > Let me rephrase then: "not to the fullest extent" > >=20 > > But you gave me the impression that not all bug reports would be "welco= me" when you said: "the vast majority of Linux and Android systems meet the= assumptions I think that this is a reasonable approach.=E2=80=9D > >=20 >=20 > These are not =E2=80=9Cbugs=E2=80=9D they are design decisions to priorit= ize the policies that are on shipping systems. >=20 > I=E2=80=99m open to contributions, but can=E2=80=99t really add support f= or DSSP on my own as I have no experience with it. >=20 > >>=20 > >> 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=E2=80=99ll be happy to look at the changes needed and give you a hand. > >=20 > > I agree, and ive said that when I said: "a few rough edges" Its close t= he usable with DSSP. It just needs to deal with some of the current assumpt= ions: > >=20 > > ill point out some: > >=20 > > 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 typeattri= bute > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its= context specs in the .cil suffixed file > > 4.=20 > > return self.diff_relative("/policy/mls", other_source) # these should b= e customizable > > return self.diff_relative("/policy/mcs", other_source) # these should b= e customizable > > return self.diff_relative("/policy/constraints", other_source) # these = should be customizable >=20 > These are from the small policy source object - which is very tied to ref= erence policy. I=E2=80=99ve just renamed that to RefPolicySource. Feel free= to send a patch to add a DsspPolicySource. >=20 > > 5. any references to type attributes should be customizable: ie. proces= s_types =3D ... filesystem_types =3D =E2=80=A6 etc > >=20 >=20 > The only one I really saw was domain, which I=E2=80=99ve made configurabl= e. But I didn=E2=80=99t search exhaustively. Again, feel free to send patch= es. >=20 > Thanks - Karl >=20 > >>=20 > >> Thanks - Karl > >>=20 > >>> Atleast this inspired me to implement policy for pip and notebook in = my personal security policy. So it was not all in vain. > >>>=20 > >>>>=20 > >>>> Thanks - Karl > >>>>=20 > >>>>>=20 > >>>>>>=20 > >>>>>> --=20 > >>>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B = 6B02 > >>>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D= 2C7B6B02 > > >>>>>> Dominick Grift > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> --=20 > >>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6= B02 > >>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2= C7B6B02 > > >>>>> Dominick Grift > >>>>=20 > >>>=20 > >>> --=20 > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > >>> Dominick Grift > >>=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkR6ysACgkQJXSOVTf5 R2kzAwwAlYCiY9wRhevvyMBhbnrY0oGQMo6uWhBIbSKVuGth3YPyyx3dvCYyDssr 7A1K4INKJoRxdXOYxUlp0VytyfIcZpNMIJuaNGmFR2R+AaWt8QwbpH4snuArDwVF 7p9e1Kz5KCkEEZrQYZhNKQje85sFvr2hsGzwMnX5eTmgiPj7Ad0aVVWgUhgiqKnm KcBjfJMAQdaks8NLhwavAbvs4EiIl/C5+F+hW9oE/aPikI3nWZ2/nVHs1h1TV82s USI6bWHcIK4ASE+cCnUjK5KAGtkLqsrkY7m5ywaHMqtHr1bGD3xBlCpMiaWyvxp/ 8NQ5vzcagz3KwUJiP3HZjMtR7lEM8YebCs+y83onh6RGxLVbjtQYOrgGxEelNAVM H4neuDRDgeqEws7XZiizzo5qraBelGBmKPa2pFUE/N6bZL6rKLwqMZZZY0kYei93 sXsycUyZXlpVT8UFd64sgSwG2hWYRoqb/Z0bx4SaJ3WxedsmtWERtVakr3Z8WQGV MTfxYkFo =GSGm -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49Gm4dA014267 for ; Tue, 9 May 2017 12:48:04 -0400 Received: by mail-wr0-f169.google.com with SMTP id z52so6972828wrc.2 for ; Tue, 09 May 2017 09:48:00 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id v7sm441528wrb.68.2017.05.09.09.47.56 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 May 2017 09:47:56 -0700 (PDT) Date: Tue, 9 May 2017 18:47:55 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170509164755.GB13560@julius> References: <20170507154759.GA31890@julius> <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> <20170509161543.GA13560@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" In-Reply-To: <20170509161543.GA13560@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > On May 8, 2017, at 4:40 PM, Dominick Grift w= rote: > > >=20 > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > >>=20 > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift = wrote: > > >>>=20 > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > >>>>=20 > > >>>>>=20 > > >>>>=20 > > >>>> I think it=E2=80=99s best to think of these as having three basic = layers: > > >>>>=20 > > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are = usable for any policy and make no assumptions about the presence of any typ= es, attributes, object classes, or permissions. So things like the rule sea= rching and information flow analysis fit into this group. This is a large p= art of the value of SPAN. > > >>>>=20 > > >>>> 2. Higher-level policy analysis methods - these are things like th= e domain_types method and the domain / type summaries. These make some mini= mal assumptions about attributes like domain. I=E2=80=99ll just mention tha= t these assumptions are very minimal and have been around for a _long_ time= =2E Domain long pre-dates the reference policy, for example. More than attr= ibutes this layer is tied to the Linux object classes and permissions. > > >>>>=20 > > >>>> 3. Example notebooks - the two example notebooks are just that - e= xamples. They probably provide a useful starting point, but as Josh points = out, should simply be modified for your specific use case. > > >>>>=20 > > >>>> So the question, then, is should the second layer (the higher-leve= l 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=E2=80=99s the great advantage of this versus o= ther analysis tools. It=E2=80=99s 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. > > >>>=20 > > >>> I don't think it will work with android. Some of it maybe but not a= ll of it. for example the source functionality appends "modules" to the sea= rch path. So i suspect that will break that functionality for Android. > > >>=20 > > >> We=E2=80=99ve not tested it for Android policies so I=E2=80=99m sure= there will be some breakage. But I hope it will be fixed to work by us or = someone soon. > > >>=20 > > >>> Thank you for giving me your opinion. At least now I know where I s= tand. > > >>=20 > > >> Where you stand? I=E2=80=99m not certain what you mean and was not t= rying to say something about you personally. > > >=20 > > > 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 th= ere). 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 illu= sions that SPAN will ever be perfect (or close to perfect) > > >=20 > >=20 > > Shrug. SELinux is =E2=80=9Cbigger=E2=80=9D than the current set of obje= ct classes and access vectors or the components of the security context. Ye= t we still have to write policy using those. Abstraction is a useful tool, = but too much abstraction interferes with getting work done clearly. > >=20 > > Ultimately SPAN has to make some assumptions about how policy works to = do any higher-level analysis (a problem that SETools doesn=E2=80=99t really= have because it doesn=E2=80=99t do much of the higher-level analysis that = I=E2=80=99m talking about). Making that somewhat configurable is fine, but = not at the cost of comprehensibility. When we hit that point it=E2=80=99s b= etter just to split the higher-level analysis methods into different versio= ns based the policy type. > >=20 > > Either way, I=E2=80=99m open to including the customizations or separat= e code in SPAN. > >=20 > > >>=20 > > >> I was not familiar with DSSP before (I=E2=80=99ve not done much with= SELinux for a while), but Josh pointed it out to me. From looking at it ve= ry 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 p= olicy stuff (which, honestly, is just a very small part mainly useful for d= iffing constraints). > > >>=20 > > >> And as a side note - it=E2=80=99s nice to see someone trying to writ= e a policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D attr= ibute or at least a similar concept? > > >=20 > > > Sure, but i cannot use "domain" for this because DSSP leverages names= paces. The equivalent in DSSP is =E2=80=9Csubj.subj_type_attribute" > > >=20 > >=20 > > This is just my opinion of course, but it seems counterproductive to pu= t what is clearly a global concept into a namespace. And _every_ policy tha= t I know of for something like two decades has had a domain attribute. Do y= ou really get enough benefits out of this change to outweigh the pain cause= d by changing such a long-running convention? With DSSP, except for the initial sids i suppose, nothing is global. (see d= ssp-base) It is modular and if you dont want to differentiate between subje= ct 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 m= akes 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 co= mprehensiveness. A lot is the same and this makes writing policy an intuiti= ve experience. only the name spaces are different. the macros , attributes = are all the same. Not going to deviate from that for "domain" > >=20 > > > So if the configuration file would have something like: > > >=20 > > > # process_types =3D domain > > >=20 > > > Then i would be happy because then i could edit it like: > > >=20 > > > process_types =3D subj.subj_type_attribute > > >=20 > >=20 > > I just committed a change that adds a domain_attribute instance variabl= e into the Policy class, allowing you to change this. You would use it like= this: > >=20 > > p =3D span.load_policy(=E2=80=9Csome_dssp_policy.cil=E2=80=9D) > > p.domain_attribute =3D =E2=80=9Csubj.subj_type_attribute=E2=80=9D > > p.domain_types() # This now looks for the subj.subj_type_attribute inst= ead of domain >=20 > Thanks! >=20 > I spent all day working on my analysis of unconfined access: https://gith= ub.com/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.ip= ynb >=20 > Its not so easy: >=20 > 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 an= alysis done in DSSP > 5. then i have to maintain DSSP is self (which isnt an attempt to write c= il policy from scratch i might add, its a policy that i use) >=20 > if and once i get to any significant extent productive with python then s= pan will probably be the first project i contribute to. Since my python ski= ll is 0.75 and since theres only 24 hours in a day it probably, unfortunate= ly, wont happen overnight >=20 >=20 > As for the domain vs subj.subj_type_attribute issue: i think it is worth = it yes. >=20 > Having a small set of consistent type attributes that get additional mean= ing by using them in different name spaces. >=20 > subj.subj_type_attribute (any process) > user.subj_type_attribute (any user process > user.unpriv.subj_type_attribute (any unpriv user process) >=20 > i have hundreds of these in DSSP. Theyre pretty much all consistently nam= ed. >=20 > >=20 > > If you want to send patches for similar changes I=E2=80=99ll be happy t= o review them. > >=20 > > Note that a configuration file is not really appropriate I don=E2=80=99= t think. This is a Python library and it=E2=80=99s better to just do the co= nfiguration 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 set= s the defaults as necessary. > >=20 > > >>=20 > > >>> I will not be able to leverage this solution to any significant ext= end, and the notebook and its depenedencies are pretty expensive to have ju= st for something that only works to some extent. > > >>=20 > > >> I=E2=80=99m curious what you mean by =E2=80=9Conly works to some ext= ent=E2=80=9D. Any bug reports would be welcome. > > >=20 > > > Let me rephrase then: "not to the fullest extent" > > >=20 > > > But you gave me the impression that not all bug reports would be "wel= come" when you said: "the vast majority of Linux and Android systems meet t= he assumptions I think that this is a reasonable approach.=E2=80=9D > > >=20 > >=20 > > These are not =E2=80=9Cbugs=E2=80=9D they are design decisions to prior= itize the policies that are on shipping systems. > >=20 > > I=E2=80=99m open to contributions, but can=E2=80=99t really add support= for DSSP on my own as I have no experience with it. > >=20 > > >>=20 > > >> And if you mean specifically in the context of DSSP, like I said I b= et the changes would be minimal. So if you are interested in giving it a tr= y I=E2=80=99ll be happy to look at the changes needed and give you a hand. > > >=20 > > > 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 assum= ptions: > > >=20 > > > ill point out some: > > >=20 > > > 1. return self.grep(name, "*.te", self.modules_path) # what about .ci= l suffixed files? > > > 2. return self.find_def("attribute " + name) # in CIL this is typeatt= ribute > > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has i= ts context specs in the .cil suffixed file > > > 4.=20 > > > 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) # thes= e should be customizable > >=20 > > These are from the small policy source object - which is very tied to r= eference policy. I=E2=80=99ve just renamed that to RefPolicySource. Feel fr= ee to send a patch to add a DsspPolicySource. > >=20 > > > 5. any references to type attributes should be customizable: ie. proc= ess_types =3D ... filesystem_types =3D =E2=80=A6 etc > > >=20 > >=20 > > The only one I really saw was domain, which I=E2=80=99ve made configura= ble. But I didn=E2=80=99t search exhaustively. Again, feel free to send pat= ches. > >=20 > > Thanks - Karl > >=20 > > >>=20 > > >> Thanks - Karl > > >>=20 > > >>> Atleast this inspired me to implement policy for pip and notebook i= n my personal security policy. So it was not all in vain. > > >>>=20 > > >>>>=20 > > >>>> Thanks - Karl > > >>>>=20 > > >>>>>=20 > > >>>>>>=20 > > >>>>>> --=20 > > >>>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7= B 6B02 > > >>>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F= 1D2C7B6B02 > > > >>>>>> Dominick Grift > > >>>>>=20 > > >>>>>=20 > > >>>>>=20 > > >>>>> --=20 > > >>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B= 6B02 > > >>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1= D2C7B6B02 > > > >>>>> Dominick Grift > > >>>>=20 > > >>>=20 > > >>> --=20 > > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6= B02 > > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2= C7B6B02 > > >>> Dominick Grift > > >>=20 > > >=20 > > > --=20 > > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7= B6B02 > > > Dominick Grift > >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkR8rcACgkQJXSOVTf5 R2kkCgv+PGUMBHoXcFS3xYxmyIwNm0plfXmYLpJc9bb1LGq4zrsXoR5X4/AvvIEB h5ldjSQBcjpV6JJfYeg1VEB1CJFCAW5f9H/ze1P7S6p0JhgfD9HBIoV1Tz1n1UGM K9tkdlExkM5fc8SFKjglO11LWZCv3AiWwEKBC4YbFVrQofFBKJhj5jydTtqC6xcL uEGQN/OyrXl5tbEwKk1whgZcFv/ZOdCBwyrcF8xhrHWJbrTbQZl69bL4S1b2JRir xiuHP2UPlQoDl4v3p1RhdO7bfSD+OHOCEz6wSJqqQkw/LwnZeZp3EbKLoUNojyoN e7I9n+TFjUJX2Kmm9faARODWkaP/NgeAO47ZrJeSIghJEwcqptv+t13Yda2zXyb4 22hxtOjRuP8QePdcMNXysnohUiYBucJFS+R2BcqofPHS9AY806xB4l3m4TR5rjQF 7kNAUubpJeS0V7KU9ATk+vRTKUYj18W9a7mUSMFBw66mbQbRSnCGcTnf38U3q7wR UDnHxBvb =/cz7 -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id v49HjGY5003092 for ; Tue, 9 May 2017 13:45:19 -0400 Received: by mail-wr0-f169.google.com with SMTP id l9so9284245wre.1 for ; Tue, 09 May 2017 10:45:11 -0700 (PDT) Received: from julius (84-245-30-81.dsl.cambrium.nl. [84.245.30.81]) by smtp.gmail.com with ESMTPSA id e11sm268197edd.68.2017.05.09.10.45.02 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 May 2017 10:45:02 -0700 (PDT) Date: Tue, 9 May 2017 19:45:00 +0200 From: Dominick Grift To: selinux@tycho.nsa.gov Subject: Re: Announcing SPAN: SELinux Policy Analysis Notebook Message-ID: <20170509174500.GC13560@julius> References: <590F78BA.5040800@quarksecurity.com> <20170508085555.GA3701@julius> <20170508093229.GB3701@julius> <20170508194931.GB7367@julius> <8AE6E08C-5E9B-4166-AD82-EB57DF4CAE5C@gmail.com> <20170508204053.GC7367@julius> <20170509161543.GA13560@julius> <20170509164755.GB13560@julius> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" In-Reply-To: <20170509164755.GB13560@julius> List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --+nBD6E3TurpgldQp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > >=20 > > > > On May 8, 2017, at 4:40 PM, Dominick Grift = wrote: > > > >=20 > > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > > >>=20 > > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift wrote: > > > >>>=20 > > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > > >>>>=20 > > > >>>>>=20 > > > >>>>=20 > > > >>>> I think it=E2=80=99s best to think of these as having three basi= c layers: > > > >>>>=20 > > > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these ar= e usable for any policy and make no assumptions about the presence of any t= ypes, attributes, object classes, or permissions. So things like the rule s= earching and information flow analysis fit into this group. This is a large= part of the value of SPAN. > > > >>>>=20 > > > >>>> 2. Higher-level policy analysis methods - these are things like = the domain_types method and the domain / type summaries. These make some mi= nimal assumptions about attributes like domain. I=E2=80=99ll just mention t= hat these assumptions are very minimal and have been around for a _long_ ti= me. Domain long pre-dates the reference policy, for example. More than attr= ibutes this layer is tied to the Linux object classes and permissions. > > > >>>>=20 > > > >>>> 3. Example notebooks - the two example notebooks are just that -= examples. They probably provide a useful starting point, but as Josh point= s out, should simply be modified for your specific use case. > > > >>>>=20 > > > >>>> So the question, then, is should the second layer (the higher-le= vel policy analysis methods) be made configurable. Honestly I think it woul= d be more work than just creating your own versions for a policy that break= s the assumptions. To me, that=E2=80=99s the great advantage of this versus= other analysis tools. It=E2=80=99s so simple to create quick tools that me= et your needs. And given that the vast majority of Linux and Android system= s meet the assumptions I think that this is a reasonable approach. > > > >>>=20 > > > >>> 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 s= earch path. So i suspect that will break that functionality for Android. > > > >>=20 > > > >> We=E2=80=99ve not tested it for Android policies so I=E2=80=99m su= re there will be some breakage. But I hope it will be fixed to work by us o= r someone soon. > > > >>=20 > > > >>> Thank you for giving me your opinion. At least now I know where I= stand. > > > >>=20 > > > >> Where you stand? I=E2=80=99m not certain what you mean and was not= trying to say something about you personally. > > > >=20 > > > > I didnt take it personal, That is not what I meant. To me SELinux i= s 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 tha= t 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 il= lusions that SPAN will ever be perfect (or close to perfect) > > > >=20 > > >=20 > > > Shrug. SELinux is =E2=80=9Cbigger=E2=80=9D than the current set of ob= ject 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. > > >=20 > > > Ultimately SPAN has to make some assumptions about how policy works t= o do any higher-level analysis (a problem that SETools doesn=E2=80=99t real= ly have because it doesn=E2=80=99t do much of the higher-level analysis tha= t I=E2=80=99m talking about). Making that somewhat configurable is fine, bu= t not at the cost of comprehensibility. When we hit that point it=E2=80=99s= better just to split the higher-level analysis methods into different vers= ions based the policy type. > > >=20 > > > Either way, I=E2=80=99m open to including the customizations or separ= ate code in SPAN. > > >=20 > > > >>=20 > > > >> I was not familiar with DSSP before (I=E2=80=99ve not done much wi= th 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). > > > >>=20 > > > >> And as a side note - it=E2=80=99s nice to see someone trying to wr= ite a policy from scratch in CIL. Do you have a =E2=80=9Cdomain=E2=80=9D at= tribute or at least a similar concept? > > > >=20 > > > > Sure, but i cannot use "domain" for this because DSSP leverages nam= espaces. The equivalent in DSSP is =E2=80=9Csubj.subj_type_attribute" > > > >=20 > > >=20 > > > 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 t= hat 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 cau= sed by changing such a long-running convention? >=20 > 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 sub= ject and object than you can do so with DSSP. It is modular. just remove th= e subject module and its dependencies. CIL allows one to do this because it= makes dependency resolving usable. >=20 > the subj.subj_type_attribute might sound useless but its part of the bigg= er picture. Consistency accros the policy (another core concept of dssp is = comprehensiveness. A lot is the same and this makes writing policy an intui= tive experience. only the name spaces are different. the macros , attribute= s are all the same. Not going to deviate from that for "domain" >=20 > > >=20 > > > > So if the configuration file would have something like: > > > >=20 > > > > # process_types =3D domain > > > >=20 > > > > Then i would be happy because then i could edit it like: > > > >=20 > > > > process_types =3D subj.subj_type_attribute > > > >=20 > > >=20 > > > I just committed a change that adds a domain_attribute instance varia= ble into the Policy class, allowing you to change this. You would use it li= ke this: > > >=20 > > > p =3D span.load_policy(=E2=80=9Csome_dssp_policy.cil=E2=80=9D) > > > p.domain_attribute =3D =E2=80=9Csubj.subj_type_attribute=E2=80=9D > > > p.domain_types() # This now looks for the subj.subj_type_attribute in= stead of domain > >=20 > > Thanks! > >=20 > > I spent all day working on my analysis of unconfined access: https://gi= thub.com/DefenSec/dssp2-standard/blob/master/Analysis_of_unconfined_access.= ipynb > >=20 > > Its not so easy: > >=20 > > 1. first i had to get familiar with notebook and aqcuire in a such a wa= y 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 li= ke 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) > >=20 > > 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 s= kill is 0.75 and since theres only 24 hours in a day it probably, unfortuna= tely, wont happen overnight > >=20 > >=20 > > As for the domain vs subj.subj_type_attribute issue: i think it is wort= h it yes. > >=20 > > Having a small set of consistent type attributes that get additional me= aning by using them in different name spaces. > >=20 > > subj.subj_type_attribute (any process) > > user.subj_type_attribute (any user process > > user.unpriv.subj_type_attribute (any unpriv user process) > >=20 > > i have hundreds of these in DSSP. Theyre pretty much all consistently n= amed. > >=20 > > >=20 > > > If you want to send patches for similar changes I=E2=80=99ll be happy= to review them. > > >=20 > > > Note that a configuration file is not really appropriate I don=E2=80= =99t think. This is a Python library and it=E2=80=99s better to just do the= configuration in code. If you have several changes that are needed for a d= ssp policy feel free to propose a load_dssp_policy top-level function that = sets the defaults as necessary. > > >=20 > > > >>=20 > > > >>> I will not be able to leverage this solution to any significant e= xtend, and the notebook and its depenedencies are pretty expensive to have = just for something that only works to some extent. > > > >>=20 > > > >> I=E2=80=99m curious what you mean by =E2=80=9Conly works to some e= xtent=E2=80=9D. Any bug reports would be welcome. > > > >=20 > > > > Let me rephrase then: "not to the fullest extent" > > > >=20 > > > > But you gave me the impression that not all bug reports would be "w= elcome" when you said: "the vast majority of Linux and Android systems meet= the assumptions I think that this is a reasonable approach.=E2=80=9D > > > >=20 > > >=20 > > > These are not =E2=80=9Cbugs=E2=80=9D they are design decisions to pri= oritize the policies that are on shipping systems. > > >=20 > > > I=E2=80=99m open to contributions, but can=E2=80=99t really add suppo= rt 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 r= eally 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 spa= ce becomes unusable with anything but refpolicy unless you strip out half o= f 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 > > >=20 > > > >>=20 > > > >> 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=E2=80=99ll be happy to look at the changes needed and give you a hand. > > > >=20 > > > > I agree, and ive said that when I said: "a few rough edges" Its clo= se the usable with DSSP. It just needs to deal with some of the current ass= umptions: > > > >=20 > > > > ill point out some: > > > >=20 > > > > 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 typea= ttribute > > > > 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has= its context specs in the .cil suffixed file > > > > 4.=20 > > > > return self.diff_relative("/policy/mls", other_source) # these shou= ld be customizable > > > > return self.diff_relative("/policy/mcs", other_source) # these shou= ld be customizable > > > > return self.diff_relative("/policy/constraints", other_source) # th= ese should be customizable > > >=20 > > > These are from the small policy source object - which is very tied to= reference policy. I=E2=80=99ve just renamed that to RefPolicySource. Feel = free to send a patch to add a DsspPolicySource. > > >=20 > > > > 5. any references to type attributes should be customizable: ie. pr= ocess_types =3D ... filesystem_types =3D =E2=80=A6 etc > > > >=20 > > >=20 > > > The only one I really saw was domain, which I=E2=80=99ve made configu= rable. But I didn=E2=80=99t search exhaustively. Again, feel free to send p= atches. I think your idea is better. i.e. split the refpolicy specific bits out and= put it in python3-span-refpolicy > > >=20 > > > Thanks - Karl > > >=20 > > > >>=20 > > > >> Thanks - Karl > > > >>=20 > > > >>> Atleast this inspired me to implement policy for pip and notebook= in my personal security policy. So it was not all in vain. > > > >>>=20 > > > >>>>=20 > > > >>>> Thanks - Karl > > > >>>>=20 > > > >>>>>=20 > > > >>>>>>=20 > > > >>>>>> --=20 > > > >>>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2= C7B 6B02 > > > >>>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C= 5F1D2C7B6B02 > > > > >>>>>> Dominick Grift > > > >>>>>=20 > > > >>>>>=20 > > > >>>>>=20 > > > >>>>> --=20 > > > >>>>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C= 7B 6B02 > > > >>>>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5= F1D2C7B6B02 > > > > >>>>> Dominick Grift > > > >>>>=20 > > > >>>=20 > > > >>> --=20 > > > >>> Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B= 6B02 > > > >>> https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1= D2C7B6B02 > > > >>> Dominick Grift > > > >>=20 > > > >=20 > > > > --=20 > > > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6= B02 > > > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2= C7B6B02 > > > > Dominick Grift > > >=20 > >=20 > > --=20 > > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6= B02 > > Dominick Grift >=20 >=20 >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --+nBD6E3TurpgldQp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAlkSABgACgkQJXSOVTf5 R2lOugv/ZVTJgY1Kyv64pl4rJSgrkyXm10SpQXugwn4QQDNmEhAhIiTirfGmWfSk y7U8uflRL5W/PxN+kG6aBRVza2Y0DSlaku2vUQW4D8q+E6miXqizCq0PAhi5Q8Vm AWRF8dAly5KQVQGc8DHbF/3XC++61OuCUK8Uf/PCyq85tiNMnLIug8W7Sr52v7Nc wJ0k2Q3ygGbsegOsP5W/fWaxC38anwgkN6Q2Ee+M17362OQXLWnU3VTX1TfANhMj U5P0842pSljP3IpmjNlwoOr5OSzv6YVNXBdd2Qtq+zOoUjwjx5Af367/jaA7qBjX X444RbxFwZ5RahBj2u+Iuvec65sYM2dGp+G+IF7aAbLtB9eFh6DxaR+9igC0W/2e BHWS4WaTHQ1/hbUz7o61z903RmJEqTXFBQoU0ylQNzhJjv0wu2JmV+3haE1clYm+ tFs8tJa73FkD2U77oKXS2GChIb4ETxqy2S5cMSWEJi7JZbdSDsnZnYA+9EXVQBJ4 6EOOcIGm =q56L -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--