I'm currently working on a reference policy addition to restrict access for
a given application. Up until now, I've been testing my application on a
Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
kernel, running, testing, auditing, etc.
What I found is that I ended up using a lot of RedHat specific downstream
macros, which aren't supported here upstream.
Is there a recommended way of testing reference policy code? How can I
alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
just compile the reference policy in my VM, relabel the filesystem, and
then reboot and load the reference policy into the kernel?
My host OS is running Ubuntu 14.04, so it's not very useful for debugging
SELinux things; I once tried getting SELinux running on my desktop
<https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>, but X wouldn't
start, etc. and I imagine the policy is pretty out of date.
How can I create an environment in which I can test my policy against the
program I'm aiming to constrain? (Syncthing)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160822/467268ed/attachment.html
On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> I'm currently working on a reference policy addition to restrict access for
> a given application. Up until now, I've been testing my application on a
> Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
> kernel, running, testing, auditing, etc.
>
> What I found is that I ended up using a lot of RedHat specific downstream
> macros, which aren't supported here upstream.
>
> Is there a recommended way of testing reference policy code? How can I
> alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
> just compile the reference policy in my VM, relabel the filesystem, and
> then reboot and load the reference policy into the kernel?
>
> My host OS is running Ubuntu 14.04, so it's not very useful for debugging
> SELinux things; I once tried getting SELinux running on my desktop
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>, but X wouldn't
> start, etc. and I imagine the policy is pretty out of date.
>
> How can I create an environment in which I can test my policy against the
> program I'm aiming to constrain? (Syncthing)
It does not have to be enforcing for testing purposes. So I suppose you
could just load refpolicy on f24, relabel the file system, and set it to
permissive.
You just have to ensure that your shell returns the right context with
id -Z (which should be pretty easy). Then you can start developing your
policy for your user application in permissive mode.
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160822/a32aaa3d/attachment.bin
On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> I'm currently working on a reference policy addition to restrict access for
> a given application. Up until now, I've been testing my application on a
> Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
> kernel, running, testing, auditing, etc.
>
> What I found is that I ended up using a lot of RedHat specific downstream
> macros, which aren't supported here upstream.
>
> Is there a recommended way of testing reference policy code? How can I
> alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
> just compile the reference policy in my VM, relabel the filesystem, and
> then reboot and load the reference policy into the kernel?
>
> My host OS is running Ubuntu 14.04, so it's not very useful for debugging
> SELinux things; I once tried getting SELinux running on my desktop
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>, but X wouldn't
> start, etc. and I imagine the policy is pretty out of date.
>
> How can I create an environment in which I can test my policy against the
> program I'm aiming to constrain? (Syncthing)
>
syncthing does not need X. So you can install a text-based system. f24
minimal server install maybe.
then you can just install refpolicy (make sure though to build with
init_systemd (i forgot that)
Also make sure you set selinux to permissive mode
then you can just start developing your policy.
Your query prompted me to try it out myself and record it. Most of the
video is me struggling with updating my qemu script and eventually i
realized i forgot to set init_systemd in the makefile, but its too late
for me to redo it tonight (tired). but its roughly the procedure.
https://youtu.be/9vgdHb2eXjg (its currently still processing)
Maybe tomorrow ill have another look (try it again and this time make
sure init_systemd is enabled ...
Anyhow this example does have some good information in between all the noise
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160822/8d46a23d/attachment.bin
On 23 Aug 2016 01:53, "Naftuli Tzvi Kay via refpolicy" <
[email protected]> wrote:
>
> I'm currently working on a reference policy addition to restrict access
for a given application. Up until now, I've been testing my application on
a Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
kernel, running, testing, auditing, etc.
>
> What I found is that I ended up using a lot of RedHat specific downstream
macros, which aren't supported here upstream.
>
> Is there a recommended way of testing reference policy code? How can I
alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
just compile the reference policy in my VM, relabel the filesystem, and
then reboot and load the reference policy into the kernel?
>
> My host OS is running Ubuntu 14.04, so it's not very useful for debugging
SELinux things; I once tried getting SELinux running on my desktop, but X
wouldn't start, etc. and I imagine the policy is pretty out of date.
>
> How can I create an environment in which I can test my policy against the
program I'm aiming to constrain? (Syncthing)
On my phone so not gonna be a long answer. For CI testing Travis is setup
for both refpol and the gentoo repo.
If you want a more full test you can take the gentoo hardened SELinux
stage3 tarballs and start that in a VM. Look under experimental on the
distfiles mirrors or ping me on IRC for more up to date ones. Releng is
going to be generating official weekly SELinux stage3's real-soon-now.
gentoo policy is quite a bit closer to refpol and targeted, strict, MCS
work for X and xfce. I don't use KDE or gnome so not 100? sure on their
status. MLS works mostly for console only, not tried X.
The xdg_config_* interfaces are also in gentoo and are the ones that I will
upstream soon if you wanted to target that directly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160823/3f7a9b63/attachment.html
On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> I'm currently working on a reference policy addition to restrict access for
> a given application. Up until now, I've been testing my application on a
> Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
> kernel, running, testing, auditing, etc.
>
> What I found is that I ended up using a lot of RedHat specific downstream
> macros, which aren't supported here upstream.
>
> Is there a recommended way of testing reference policy code? How can I
> alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
> just compile the reference policy in my VM, relabel the filesystem, and
> then reboot and load the reference policy into the kernel?
>
> My host OS is running Ubuntu 14.04, so it's not very useful for debugging
> SELinux things; I once tried getting SELinux running on my desktop
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>, but X wouldn't
> start, etc. and I imagine the policy is pretty out of date.
>
> How can I create an environment in which I can test my policy against the
> program I'm aiming to constrain? (Syncthing)
>
>
I spent the morning recording the full procedure of developing for
refpolicy on fedora.
I start with installing refpolicy, enabling it. then it write a simple
module on top of the installation. This is what one would do when one
wants to write a module atop of refpolicy.
I encourage you to not give up and take this final step. You are very
close, and your module so far is pretty good.
Learning how to do what is in the video is the final piece in the puzzle
i think.
The video might be long but its comprehensive (the video might still be
processing on youtube but it will become available shortly:
https://www.youtube.com/watch?v=XIyxW4qT0UM
If you have any questions, then please do not hesitate to ask
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160823/17af48b3/attachment-0001.bin
Don't worry, I'm not giving up :) It might just take a while before I have
something working.
Would the reference policy ever be interested in having a Vagrant VM setup
for testing policy rules and everything? I'd be happy to contribute that
back upstream.
Thanks,
- Naftuli Tzvi
On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift <[email protected]>
wrote:
> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> > I'm currently working on a reference policy addition to restrict access
> for
> > a given application. Up until now, I've been testing my application on a
> > Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
> > kernel, running, testing, auditing, etc.
> >
> > What I found is that I ended up using a lot of RedHat specific downstream
> > macros, which aren't supported here upstream.
> >
> > Is there a recommended way of testing reference policy code? How can I
> > alter my Fedora Vagrant VM setup to cover the use case I'm after? Should
> I
> > just compile the reference policy in my VM, relabel the filesystem, and
> > then reboot and load the reference policy into the kernel?
> >
> > My host OS is running Ubuntu 14.04, so it's not very useful for debugging
> > SELinux things; I once tried getting SELinux running on my desktop
> > <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>, but X wouldn't
> > start, etc. and I imagine the policy is pretty out of date.
> >
> > How can I create an environment in which I can test my policy against the
> > program I'm aiming to constrain? (Syncthing)
> >
> >
>
> I spent the morning recording the full procedure of developing for
> refpolicy on fedora.
>
> I start with installing refpolicy, enabling it. then it write a simple
> module on top of the installation. This is what one would do when one
> wants to write a module atop of refpolicy.
>
> I encourage you to not give up and take this final step. You are very
> close, and your module so far is pretty good.
>
> Learning how to do what is in the video is the final piece in the puzzle
> i think.
>
> The video might be long but its comprehensive (the video might still be
> processing on youtube but it will become available shortly:
>
> https://www.youtube.com/watch?v=XIyxW4qT0UM
>
> If you have any questions, then please do not hesitate to ask
>
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160823/f2005e52/attachment.html
On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
> Don't worry, I'm not giving up :) It might just take a while before I
> have something working.
>
> Would the reference policy ever be interested in having a Vagrant VM
> setup for testing policy rules and everything? I'd be happy to
> contribute that back upstream.
What kind of testing did you have in mind? Just a compile/link test or
something more? If it's just compile/link then the CI tests are sufficient.
> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> > I'm currently working on a reference policy addition to restrict access for
> > a given application. Up until now, I've been testing my application on a
> > Fedora 24 Vagrant VM, compiling a non-base module and loading it into the
> > kernel, running, testing, auditing, etc.
> >
> > What I found is that I ended up using a lot of RedHat specific downstream
> > macros, which aren't supported here upstream.
> >
> > Is there a recommended way of testing reference policy code? How can I
> > alter my Fedora Vagrant VM setup to cover the use case I'm after? Should I
> > just compile the reference policy in my VM, relabel the filesystem, and
> > then reboot and load the reference policy into the kernel?
> >
> > My host OS is running Ubuntu 14.04, so it's not very useful for debugging
> > SELinux things; I once tried getting SELinux running on my desktop
> > <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>, but X wouldn't
> > start, etc. and I imagine the policy is pretty out of date.
> >
> > How can I create an environment in which I can test my policy against the
> > program I'm aiming to constrain? (Syncthing)
> >
> >
>
> I spent the morning recording the full procedure of developing for
> refpolicy on fedora.
>
> I start with installing refpolicy, enabling it. then it write a simple
> module on top of the installation. This is what one would do when one
> wants to write a module atop of refpolicy.
>
> I encourage you to not give up and take this final step. You are very
> close, and your module so far is pretty good.
>
> Learning how to do what is in the video is the final piece in the puzzle
> i think.
>
> The video might be long but its comprehensive (the video might still be
> processing on youtube but it will become available shortly:
>
> https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>
> If you have any questions, then please do not hesitate to ask
>
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com <mailto:[email protected]>
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
> >
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> Dominick Grift
>
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Chris PeBenito
I was thinking of making a Vagrant environment where users can test their
applications on a system running the currently checked out master of
refpolicy. This will make it easier for me to update my policy for
Syncthing for instance.
In short, an environment to:
1. compile the reference policy
2. install it in the running kernel
3. install applications and do integration tests of the policy against
actual running binaries when developing new policies for applications
Thanks,
- Naftuli Tzvi
On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito <[email protected]> wrote:
> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>
>> Don't worry, I'm not giving up :) It might just take a while before I
>> have something working.
>>
>> Would the reference policy ever be interested in having a Vagrant VM
>> setup for testing policy rules and everything? I'd be happy to
>> contribute that back upstream.
>>
>
> What kind of testing did you have in mind? Just a compile/link test or
> something more? If it's just compile/link then the CI tests are sufficient.
>
>
> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
>> > I'm currently working on a reference policy addition to restrict
>> access for
>> > a given application. Up until now, I've been testing my application
>> on a
>> > Fedora 24 Vagrant VM, compiling a non-base module and loading it
>> into the
>> > kernel, running, testing, auditing, etc.
>> >
>> > What I found is that I ended up using a lot of RedHat specific
>> downstream
>> > macros, which aren't supported here upstream.
>> >
>> > Is there a recommended way of testing reference policy code? How
>> can I
>> > alter my Fedora Vagrant VM setup to cover the use case I'm after?
>> Should I
>> > just compile the reference policy in my VM, relabel the filesystem,
>> and
>> > then reboot and load the reference policy into the kernel?
>> >
>> > My host OS is running Ubuntu 14.04, so it's not very useful for
>> debugging
>> > SELinux things; I once tried getting SELinux running on my desktop
>> > <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>, but X
>> wouldn't
>> > start, etc. and I imagine the policy is pretty out of date.
>> >
>> > How can I create an environment in which I can test my policy
>> against the
>> > program I'm aiming to constrain? (Syncthing)
>> >
>> >
>>
>> I spent the morning recording the full procedure of developing for
>> refpolicy on fedora.
>>
>> I start with installing refpolicy, enabling it. then it write a simple
>> module on top of the installation. This is what one would do when one
>> wants to write a module atop of refpolicy.
>>
>> I encourage you to not give up and take this final step. You are very
>> close, and your module so far is pretty good.
>>
>> Learning how to do what is in the video is the final piece in the
>> puzzle
>> i think.
>>
>> The video might be long but its comprehensive (the video might still
>> be
>> processing on youtube but it will become available shortly:
>>
>> https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>>
>> If you have any questions, then please do not hesitate to ask
>>
>> >
>> > _______________________________________________
>> > refpolicy mailing list
>> > refpolicy at oss.tresys.com <mailto:[email protected]>
>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>> >
>>
>>
>> --
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F
>> 1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>
>> Dominick Grift
>>
>>
>>
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
>>
>
> --
> Chris PeBenito
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160824/3e3aaf06/attachment-0001.html
On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
> I was thinking of making a Vagrant environment where users can test
> their applications on a system running the currently checked out master
> of refpolicy. This will make it easier for me to update my policy for
> Syncthing for instance.
>
> In short, an environment to:
> 1. compile the reference policy
> 2. install it in the running kernel
> 3. install applications and do integration tests of the policy against
> actual running binaries when developing new policies for applications
Will you be including configuration/scripts for provisioning too? How
would the provisioning be done? Shell scripts?
> On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>
> Don't worry, I'm not giving up :) It might just take a while
> before I
> have something working.
>
> Would the reference policy ever be interested in having a Vagrant VM
> setup for testing policy rules and everything? I'd be happy to
> contribute that back upstream.
>
>
> What kind of testing did you have in mind? Just a compile/link test
> or something more? If it's just compile/link then the CI tests are
> sufficient.
>
>
> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift
> <dac.override at gmail.com <mailto:[email protected]>
> <mailto:dac.override at gmail.com <mailto:[email protected]>>>
> wrote:
>
> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
> > I'm currently working on a reference policy addition to
> restrict access for
> > a given application. Up until now, I've been testing my
> application on a
> > Fedora 24 Vagrant VM, compiling a non-base module and
> loading it into the
> > kernel, running, testing, auditing, etc.
> >
> > What I found is that I ended up using a lot of RedHat
> specific downstream
> > macros, which aren't supported here upstream.
> >
> > Is there a recommended way of testing reference policy
> code? How can I
> > alter my Fedora Vagrant VM setup to cover the use case I'm
> after? Should I
> > just compile the reference policy in my VM, relabel the
> filesystem, and
> > then reboot and load the reference policy into the kernel?
> >
> > My host OS is running Ubuntu 14.04, so it's not very
> useful for debugging
> > SELinux things; I once tried getting SELinux running on my
> desktop
> > <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>>, but X
> wouldn't
> > start, etc. and I imagine the policy is pretty out of date.
> >
> > How can I create an environment in which I can test my
> policy against the
> > program I'm aiming to constrain? (Syncthing)
> >
> >
>
> I spent the morning recording the full procedure of
> developing for
> refpolicy on fedora.
>
> I start with installing refpolicy, enabling it. then it
> write a simple
> module on top of the installation. This is what one would do
> when one
> wants to write a module atop of refpolicy.
>
> I encourage you to not give up and take this final step. You
> are very
> close, and your module so far is pretty good.
>
> Learning how to do what is in the video is the final piece
> in the puzzle
> i think.
>
> The video might be long but its comprehensive (the video
> might still be
> processing on youtube but it will become available shortly:
>
> https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
> <https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>
>
> If you have any questions, then please do not hesitate to ask
>
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com <mailto:[email protected]>
> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]>>
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
> <http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
> >
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D
> 2C7B 6B02
>
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
> Dominick Grift
>
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com <mailto:[email protected]>
> http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>
>
>
> --
> Chris PeBenito
>
>
--
Chris PeBenito
I'm hoping to have as few scripts as possible. Is there a preference here?
I could use Ansible, but if shell scripts are the most portable thing with
the least dependencies, I can do that.
Thanks,
- Naftuli Tzvi
On Thu, Aug 25, 2016 at 3:39 PM, Chris PeBenito <[email protected]> wrote:
> On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
>
>> I was thinking of making a Vagrant environment where users can test
>> their applications on a system running the currently checked out master
>> of refpolicy. This will make it easier for me to update my policy for
>> Syncthing for instance.
>>
>> In short, an environment to:
>> 1. compile the reference policy
>> 2. install it in the running kernel
>> 3. install applications and do integration tests of the policy against
>> actual running binaries when developing new policies for applications
>>
>
> Will you be including configuration/scripts for provisioning too? How
> would the provisioning be done? Shell scripts?
>
>
>
> On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>>
>> Don't worry, I'm not giving up :) It might just take a while
>> before I
>> have something working.
>>
>> Would the reference policy ever be interested in having a Vagrant
>> VM
>> setup for testing policy rules and everything? I'd be happy to
>> contribute that back upstream.
>>
>>
>> What kind of testing did you have in mind? Just a compile/link test
>> or something more? If it's just compile/link then the CI tests are
>> sufficient.
>>
>>
>> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift
>> <dac.override at gmail.com <mailto:[email protected]>
>> <mailto:dac.override at gmail.com <mailto:[email protected]>>>
>>
>> wrote:
>>
>> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via refpolicy wrote:
>> > I'm currently working on a reference policy addition to
>> restrict access for
>> > a given application. Up until now, I've been testing my
>> application on a
>> > Fedora 24 Vagrant VM, compiling a non-base module and
>> loading it into the
>> > kernel, running, testing, auditing, etc.
>> >
>> > What I found is that I ended up using a lot of RedHat
>> specific downstream
>> > macros, which aren't supported here upstream.
>> >
>> > Is there a recommended way of testing reference policy
>> code? How can I
>> > alter my Fedora Vagrant VM setup to cover the use case I'm
>> after? Should I
>> > just compile the reference policy in my VM, relabel the
>> filesystem, and
>> > then reboot and load the reference policy into the kernel?
>> >
>> > My host OS is running Ubuntu 14.04, so it's not very
>> useful for debugging
>> > SELinux things; I once tried getting SELinux running on my
>> desktop
>> > <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>>, but X
>> wouldn't
>> > start, etc. and I imagine the policy is pretty out of date.
>> >
>> > How can I create an environment in which I can test my
>> policy against the
>> > program I'm aiming to constrain? (Syncthing)
>> >
>> >
>>
>> I spent the morning recording the full procedure of
>> developing for
>> refpolicy on fedora.
>>
>> I start with installing refpolicy, enabling it. then it
>> write a simple
>> module on top of the installation. This is what one would do
>> when one
>> wants to write a module atop of refpolicy.
>>
>> I encourage you to not give up and take this final step. You
>> are very
>> close, and your module so far is pretty good.
>>
>> Learning how to do what is in the video is the final piece
>> in the puzzle
>> i think.
>>
>> The video might be long but its comprehensive (the video
>> might still be
>> processing on youtube but it will become available shortly:
>>
>> https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>
>>
>> If you have any questions, then please do not hesitate to ask
>>
>> >
>> > _______________________________________________
>> > refpolicy mailing list
>> > refpolicy at oss.tresys.com <mailto:[email protected]>
>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>> >>
>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>> >
>>
>>
>> --
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D
>> 2C7B 6B02
>>
>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F
>> 1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>
>>
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>>
>> Dominick Grift
>>
>>
>>
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com <mailto:[email protected]>
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>>
>>
>>
>> --
>> Chris PeBenito
>>
>>
>>
>
> --
> Chris PeBenito
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160825/99527525/attachment-0001.html
On 08/25/16 18:48, Naftuli Tzvi Kay wrote:
> I'm hoping to have as few scripts as possible. Is there a preference
> here? I could use Ansible, but if shell scripts are the most portable
> thing with the least dependencies, I can do that.
I'd prefer shell scripts, because it doesn't incur even more
dependencies, but if they get too ugly, I'd be willing to entertain
something like an ansible playbook.
> On Thu, Aug 25, 2016 at 3:39 PM, Chris PeBenito <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
>
> I was thinking of making a Vagrant environment where users can test
> their applications on a system running the currently checked out
> master
> of refpolicy. This will make it easier for me to update my
> policy for
> Syncthing for instance.
>
> In short, an environment to:
> 1. compile the reference policy
> 2. install it in the running kernel
> 3. install applications and do integration tests of the policy
> against
> actual running binaries when developing new policies for
> applications
>
>
> Will you be including configuration/scripts for provisioning too?
> How would the provisioning be done? Shell scripts?
>
>
>
> On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito
> <pebenito at ieee.org <mailto:[email protected]>
> <mailto:pebenito at ieee.org <mailto:[email protected]>>> wrote:
>
> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>
> Don't worry, I'm not giving up :) It might just take a while
> before I
> have something working.
>
> Would the reference policy ever be interested in having
> a Vagrant VM
> setup for testing policy rules and everything? I'd be
> happy to
> contribute that back upstream.
>
>
> What kind of testing did you have in mind? Just a
> compile/link test
> or something more? If it's just compile/link then the CI
> tests are
> sufficient.
>
>
> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift
> <dac.override at gmail.com <mailto:[email protected]>
> <mailto:dac.override at gmail.com <mailto:[email protected]>>
> <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>>
>
> wrote:
>
> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via
> refpolicy wrote:
> > I'm currently working on a reference policy
> addition to
> restrict access for
> > a given application. Up until now, I've been
> testing my
> application on a
> > Fedora 24 Vagrant VM, compiling a non-base module and
> loading it into the
> > kernel, running, testing, auditing, etc.
> >
> > What I found is that I ended up using a lot of RedHat
> specific downstream
> > macros, which aren't supported here upstream.
> >
> > Is there a recommended way of testing reference policy
> code? How can I
> > alter my Fedora Vagrant VM setup to cover the use
> case I'm
> after? Should I
> > just compile the reference policy in my VM,
> relabel the
> filesystem, and
> > then reboot and load the reference policy into the
> kernel?
> >
> > My host OS is running Ubuntu 14.04, so it's not very
> useful for debugging
> > SELinux things; I once tried getting SELinux
> running on my
> desktop
> >
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>
>
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>>>, but X
> wouldn't
> > start, etc. and I imagine the policy is pretty out
> of date.
> >
> > How can I create an environment in which I can test my
> policy against the
> > program I'm aiming to constrain? (Syncthing)
> >
> >
>
> I spent the morning recording the full procedure of
> developing for
> refpolicy on fedora.
>
> I start with installing refpolicy, enabling it. then it
> write a simple
> module on top of the installation. This is what one
> would do
> when one
> wants to write a module atop of refpolicy.
>
> I encourage you to not give up and take this final
> step. You
> are very
> close, and your module so far is pretty good.
>
> Learning how to do what is in the video is the final
> piece
> in the puzzle
> i think.
>
> The video might be long but its comprehensive (the video
> might still be
> processing on youtube but it will become available
> shortly:
>
> https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
> <https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>
> <https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
> <https://www.youtube.com/watch?v=XIyxW4qT0UM
> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>>
>
> If you have any questions, then please do not
> hesitate to ask
>
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> <mailto:[email protected]>
> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]>>
> <mailto:[email protected]
> <mailto:[email protected]>
> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]>>>
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
> <http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
> <http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
> <http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>>>
> >
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5
> 3B6C 5F1D
> 2C7B 6B02
>
>
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>
>
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
>
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>>>
> Dominick Grift
>
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> <mailto:[email protected]>
> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]>>
> http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>
> <http://oss.tresys.com/mailman/listinfo/refpolicy
> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>
>
>
> --
> Chris PeBenito
>
>
>
>
> --
> Chris PeBenito
>
>
--
Chris PeBenito
Okay, I'll post back when I have something significant to report.
Thanks,
- Naftuli Tzvi
On Thu, Aug 25, 2016 at 3:51 PM, Chris PeBenito <[email protected]> wrote:
> On 08/25/16 18:48, Naftuli Tzvi Kay wrote:
>
>> I'm hoping to have as few scripts as possible. Is there a preference
>> here? I could use Ansible, but if shell scripts are the most portable
>> thing with the least dependencies, I can do that.
>>
>
> I'd prefer shell scripts, because it doesn't incur even more dependencies,
> but if they get too ugly, I'd be willing to entertain something like an
> ansible playbook.
>
>
>
> On Thu, Aug 25, 2016 at 3:39 PM, Chris PeBenito <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
>>
>> I was thinking of making a Vagrant environment where users can
>> test
>> their applications on a system running the currently checked out
>> master
>> of refpolicy. This will make it easier for me to update my
>> policy for
>> Syncthing for instance.
>>
>> In short, an environment to:
>> 1. compile the reference policy
>> 2. install it in the running kernel
>> 3. install applications and do integration tests of the policy
>> against
>> actual running binaries when developing new policies for
>> applications
>>
>>
>> Will you be including configuration/scripts for provisioning too?
>> How would the provisioning be done? Shell scripts?
>>
>>
>>
>> On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito
>> <pebenito at ieee.org <mailto:[email protected]>
>> <mailto:pebenito at ieee.org <mailto:[email protected]>>> wrote:
>>
>> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>>
>> Don't worry, I'm not giving up :) It might just take a
>> while
>> before I
>> have something working.
>>
>> Would the reference policy ever be interested in having
>> a Vagrant VM
>> setup for testing policy rules and everything? I'd be
>> happy to
>> contribute that back upstream.
>>
>>
>> What kind of testing did you have in mind? Just a
>> compile/link test
>> or something more? If it's just compile/link then the CI
>> tests are
>> sufficient.
>>
>>
>> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift
>> <dac.override at gmail.com <mailto:[email protected]>
>> <mailto:dac.override at gmail.com <mailto:[email protected]>>
>> <mailto:[email protected]
>> <mailto:[email protected]> <mailto:[email protected]
>> <mailto:[email protected]>>>>
>>
>> wrote:
>>
>> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via
>> refpolicy wrote:
>> > I'm currently working on a reference policy
>> addition to
>> restrict access for
>> > a given application. Up until now, I've been
>> testing my
>> application on a
>> > Fedora 24 Vagrant VM, compiling a non-base module
>> and
>> loading it into the
>> > kernel, running, testing, auditing, etc.
>> >
>> > What I found is that I ended up using a lot of
>> RedHat
>> specific downstream
>> > macros, which aren't supported here upstream.
>> >
>> > Is there a recommended way of testing reference
>> policy
>> code? How can I
>> > alter my Fedora Vagrant VM setup to cover the use
>> case I'm
>> after? Should I
>> > just compile the reference policy in my VM,
>> relabel the
>> filesystem, and
>> > then reboot and load the reference policy into the
>> kernel?
>> >
>> > My host OS is running Ubuntu 14.04, so it's not very
>> useful for debugging
>> > SELinux things; I once tried getting SELinux
>> running on my
>> desktop
>> >
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>
>>
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>>>, but X
>> wouldn't
>> > start, etc. and I imagine the policy is pretty out
>> of date.
>> >
>> > How can I create an environment in which I can test
>> my
>> policy against the
>> > program I'm aiming to constrain? (Syncthing)
>> >
>> >
>>
>> I spent the morning recording the full procedure of
>> developing for
>> refpolicy on fedora.
>>
>> I start with installing refpolicy, enabling it. then
>> it
>> write a simple
>> module on top of the installation. This is what one
>> would do
>> when one
>> wants to write a module atop of refpolicy.
>>
>> I encourage you to not give up and take this final
>> step. You
>> are very
>> close, and your module so far is pretty good.
>>
>> Learning how to do what is in the video is the final
>> piece
>> in the puzzle
>> i think.
>>
>> The video might be long but its comprehensive (the
>> video
>> might still be
>> processing on youtube but it will become available
>> shortly:
>>
>> https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>>
>>
>> If you have any questions, then please do not
>> hesitate to ask
>>
>> >
>> > _______________________________________________
>> > refpolicy mailing list
>> > refpolicy at oss.tresys.com
>> <mailto:[email protected]>
>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>> >>
>> <mailto:[email protected]
>> <mailto:[email protected]>
>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>> >>>
>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>>
>> >
>>
>>
>> --
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5
>> 3B6C 5F1D
>> 2C7B 6B02
>>
>>
>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F
>> 1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>
>>
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>>
>>
>>
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>
>>
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02
>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>> F1D2C7B6B02>>>
>> Dominick Grift
>>
>>
>>
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> <mailto:[email protected]>
>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>> >>
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>>
>>
>>
>> --
>> Chris PeBenito
>>
>>
>>
>>
>> --
>> Chris PeBenito
>>
>>
>>
>
> --
> Chris PeBenito
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160825/7ddfea51/attachment-0001.html
Would most of you appreciate a Fedora VM or a CentOS VM for the Vagrant box?
On Aug 25, 2016 15:54, "Naftuli Tzvi Kay" <[email protected]> wrote:
> Okay, I'll post back when I have something significant to report.
>
> Thanks,
> - Naftuli Tzvi
>
> On Thu, Aug 25, 2016 at 3:51 PM, Chris PeBenito <[email protected]> wrote:
>
>> On 08/25/16 18:48, Naftuli Tzvi Kay wrote:
>>
>>> I'm hoping to have as few scripts as possible. Is there a preference
>>> here? I could use Ansible, but if shell scripts are the most portable
>>> thing with the least dependencies, I can do that.
>>>
>>
>> I'd prefer shell scripts, because it doesn't incur even more
>> dependencies, but if they get too ugly, I'd be willing to entertain
>> something like an ansible playbook.
>>
>>
>>
>> On Thu, Aug 25, 2016 at 3:39 PM, Chris PeBenito <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
>>>
>>> I was thinking of making a Vagrant environment where users can
>>> test
>>> their applications on a system running the currently checked out
>>> master
>>> of refpolicy. This will make it easier for me to update my
>>> policy for
>>> Syncthing for instance.
>>>
>>> In short, an environment to:
>>> 1. compile the reference policy
>>> 2. install it in the running kernel
>>> 3. install applications and do integration tests of the policy
>>> against
>>> actual running binaries when developing new policies for
>>> applications
>>>
>>>
>>> Will you be including configuration/scripts for provisioning too?
>>> How would the provisioning be done? Shell scripts?
>>>
>>>
>>>
>>> On Wed, Aug 24, 2016 at 3:12 PM, Chris PeBenito
>>> <pebenito at ieee.org <mailto:[email protected]>
>>> <mailto:pebenito at ieee.org <mailto:[email protected]>>> wrote:
>>>
>>> On 08/23/16 23:35, Naftuli Tzvi Kay via refpolicy wrote:
>>>
>>> Don't worry, I'm not giving up :) It might just take a
>>> while
>>> before I
>>> have something working.
>>>
>>> Would the reference policy ever be interested in having
>>> a Vagrant VM
>>> setup for testing policy rules and everything? I'd be
>>> happy to
>>> contribute that back upstream.
>>>
>>>
>>> What kind of testing did you have in mind? Just a
>>> compile/link test
>>> or something more? If it's just compile/link then the CI
>>> tests are
>>> sufficient.
>>>
>>>
>>> On Tue, Aug 23, 2016 at 2:36 AM, Dominick Grift
>>> <dac.override at gmail.com <mailto:[email protected]>
>>> <mailto:dac.override at gmail.com <mailto:[email protected]>>
>>> <mailto:[email protected]
>>> <mailto:[email protected]> <mailto:[email protected]
>>> <mailto:[email protected]>>>>
>>>
>>> wrote:
>>>
>>> On 08/22/2016 07:52 PM, Naftuli Tzvi Kay via
>>> refpolicy wrote:
>>> > I'm currently working on a reference policy
>>> addition to
>>> restrict access for
>>> > a given application. Up until now, I've been
>>> testing my
>>> application on a
>>> > Fedora 24 Vagrant VM, compiling a non-base module
>>> and
>>> loading it into the
>>> > kernel, running, testing, auditing, etc.
>>> >
>>> > What I found is that I ended up using a lot of
>>> RedHat
>>> specific downstream
>>> > macros, which aren't supported here upstream.
>>> >
>>> > Is there a recommended way of testing reference
>>> policy
>>> code? How can I
>>> > alter my Fedora Vagrant VM setup to cover the use
>>> case I'm
>>> after? Should I
>>> > just compile the reference policy in my VM,
>>> relabel the
>>> filesystem, and
>>> > then reboot and load the reference policy into the
>>> kernel?
>>> >
>>> > My host OS is running Ubuntu 14.04, so it's not
>>> very
>>> useful for debugging
>>> > SELinux things; I once tried getting SELinux
>>> running on my
>>> desktop
>>> >
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>
>>>
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu
>>> <https://rfkrocktk.github.io/2015/12/selinux-on-ubuntu>>>>, but
>>> X
>>> wouldn't
>>> > start, etc. and I imagine the policy is pretty out
>>> of date.
>>> >
>>> > How can I create an environment in which I can
>>> test my
>>> policy against the
>>> > program I'm aiming to constrain? (Syncthing)
>>> >
>>> >
>>>
>>> I spent the morning recording the full procedure of
>>> developing for
>>> refpolicy on fedora.
>>>
>>> I start with installing refpolicy, enabling it. then
>>> it
>>> write a simple
>>> module on top of the installation. This is what one
>>> would do
>>> when one
>>> wants to write a module atop of refpolicy.
>>>
>>> I encourage you to not give up and take this final
>>> step. You
>>> are very
>>> close, and your module so far is pretty good.
>>>
>>> Learning how to do what is in the video is the final
>>> piece
>>> in the puzzle
>>> i think.
>>>
>>> The video might be long but its comprehensive (the
>>> video
>>> might still be
>>> processing on youtube but it will become available
>>> shortly:
>>>
>>> https://www.youtube.com/watch?v=XIyxW4qT0UM
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM
>>> <https://www.youtube.com/watch?v=XIyxW4qT0UM>>>
>>>
>>> If you have any questions, then please do not
>>> hesitate to ask
>>>
>>> >
>>> > _______________________________________________
>>> > refpolicy mailing list
>>> > refpolicy at oss.tresys.com
>>> <mailto:[email protected]>
>>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>>> om>>
>>> <mailto:[email protected]
>>> <mailto:[email protected]>
>>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>>> om>>>
>>> > http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>>
>>> >
>>>
>>>
>>> --
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5
>>> 3B6C 5F1D
>>> 2C7B 6B02
>>>
>>>
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F
>>> 1D2C7B6B02
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02>
>>>
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02>>
>>>
>>>
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02>
>>>
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02
>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5
>>> F1D2C7B6B02>>>
>>> Dominick Grift
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> <mailto:[email protected]>
>>> <mailto:refpolicy at oss.tresys.com <mailto:[email protected]
>>> om>>
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy
>>> <http://oss.tresys.com/mailman/listinfo/refpolicy>>
>>>
>>>
>>>
>>> --
>>> Chris PeBenito
>>>
>>>
>>>
>>>
>>> --
>>> Chris PeBenito
>>>
>>>
>>>
>>
>> --
>> Chris PeBenito
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160828/1e62a264/attachment-0001.html
On 08/28/16 14:25, Naftuli Tzvi Kay wrote:
> Would most of you appreciate a Fedora VM or a CentOS VM for the Vagrant box?
A minimal Fedora would probably be a better bet, as it is more up to date.
On a side note, please do not send HTML emails to the list.
> On Aug 25, 2016 15:54, "Naftuli Tzvi Kay" <[email protected]
> <mailto:[email protected]>> wrote:
>
> Okay, I'll post back when I have something significant to report.
>
> Thanks,
> - Naftuli Tzvi
>
> On Thu, Aug 25, 2016 at 3:51 PM, Chris PeBenito <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 08/25/16 18:48, Naftuli Tzvi Kay wrote:
>
> I'm hoping to have as few scripts as possible. Is there a
> preference
> here? I could use Ansible, but if shell scripts are the most
> portable
> thing with the least dependencies, I can do that.
>
>
> I'd prefer shell scripts, because it doesn't incur even more
> dependencies, but if they get too ugly, I'd be willing to
> entertain something like an ansible playbook.
>
>
>
> On Thu, Aug 25, 2016 at 3:39 PM, Chris PeBenito
> <pebenito at ieee.org <mailto:[email protected]>
> <mailto:pebenito at ieee.org <mailto:[email protected]>>> wrote:
>
> On 08/24/16 18:14, Naftuli Tzvi Kay wrote:
>
> I was thinking of making a Vagrant environment where
> users can test
> their applications on a system running the currently
> checked out
> master
> of refpolicy. This will make it easier for me to
> update my
> policy for
> Syncthing for instance.
>
> In short, an environment to:
> 1. compile the reference policy
> 2. install it in the running kernel
> 3. install applications and do integration tests of
> the policy
> against
> actual running binaries when developing new policies for
> applications
>
>
> Will you be including configuration/scripts for
> provisioning too?
> How would the provisioning be done? Shell scripts?
--
Chris PeBenito