From: rfkrocktk@gmail.com (Naftuli Tzvi Kay) Date: Thu, 25 Aug 2016 15:54:40 -0700 Subject: [refpolicy] Testing in the Reference Policy In-Reply-To: References: <9e6f676d-edd4-e33c-a861-9334adfea081@gmail.com> <9b6be580-6efd-fa8f-daa8-94e371cc4bf3@ieee.org> <500fc9cb-11ee-18b9-c049-4587ba29633a@ieee.org>

Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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 > > 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 >> >> >> 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 >> >> > >> > > >>> >> >> 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 >> > >> > >> > > >> >> > >> > >>>, 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=0x3B6C5F >> 1D2C7B6B02 >> > F1D2C7B6B02> >> >> > F1D2C7B6B02 >> > F1D2C7B6B02>> >> >> >> > F1D2C7B6B02 >> > F1D2C7B6B02> >> >> > F1D2C7B6B02 >> > F1D2C7B6B02>>> >> Dominick Grift >> >> >> >> >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> >> > >> >> 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