On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel wrote: > On 5/22/20 1:24 PM, Nico Kadel-Garcia wrote: > > > On Fri, May 22, 2020 at 10:31 AM Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > > >> I am working on our application whitelisting daemon. > > Interesting concept---could you please elaborate on your design? It > sounds useful but also challenging, as Nico points out. There is some information about it here: https://static.sched.com/hosted_files/lssna19/ce/application-whitlisting-sgrubb.pdf >From the speech I gave at the Linux Security Summit last August. The design has evolved quite a bit from then. And the 1.0 release should be coming up this weekend. More info on the project page: https://github.com/linux-application-whitelisting/fapolicyd If you wanted to try it out, I'd recommend the github copy. This one can do integrity enforcement and even teamed up with IMA so they cross check each other by validating IMA's xattrs with rpmdb's info. > On what level do you plan to whitelist---kernel/syscall? shell? all > shells? execute or open permision request. > >> It uses the rpmdb to > >> > >> derive trust in what's on disk. If we use the whole rpmdb, then the > >> number of files is large. So, to prune the amount of entries in the > >> trust db down to a reasonable number, I thought we could jettison > >> anything in /usr/share.> > > I think that you're being very optimistic. Python modules, for > > instance, include executable scripts in their documentation stored in > > /usr/share/doc/ > > > In general, data is code is data. I know this argument well (Weird Machines). I was making the same argument 10 years ago. :-) But hairs have to be split and uninteresting files dropped. -Steve > For instance, any configuration file > can be seen as essentially a data-driven execution which, if you squint > hard, is theoretically exploitable just like an interpreter reading a > shell program. They just live on different points of the same spectrum: > on one end, the shell will read 'rm a' and delete file 'a', while a > hypothetical application might have a configuration file like this: > > data-source /dev/null > > data-output a > > and the end result will be (almost) the same. > > As another example I used to write configuration for Tcl scripts as Tcl > code; then, reading/parsing config scripts was just open/read/eval. If > this revolts you, please consider that Tcl has a simple verb-noun syntax > that makes such files readable and nice to use, as well as a nice > sandboxing mechanism that can be used to defang eval if needed (I didn't > care that much because I was writing for in-house use, but it could be > used to write a secure application if that was the concern). > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxx > g _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
