From: rfkrocktk@gmail.com (Naftuli Tzvi Kay) Date: Sun, 28 Aug 2016 11:25:33 -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 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" 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 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 >>> >>> >> om>> >>> >> >>> >> om>>> >>> > 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 >>> >>> >> om>> >>> 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