On Friday, May 22, 2020 3:19:20 PM EDT David Malcolm wrote: > Your email talks about "application whitelisting" and "executables", > and this thread seems to be getting in to the weeds about things like > the distinction between scripts vs machine code, and modules vs > scripts; code vs data. But it's real. I was just curious if there was some kind of standard that we should be following that says where to expect obvious code such as all the python and javascript so that these do not get dropped. > Would it be helpful to approach this from a higher-level point of view? > Presumably your goal is to enforce some kind of security boundary, > along the lines of "only blessed things can be run". What is that > boundary? The boundary is known things. > What kinds of threat do you have in mind, and how might this > whitelisting daemon block them? (is there a web page somewhere for the > project?) (also: what's the user experience?) It uses fanotify which is a hook made for virus scanners to make a decision. It checks the file to see if we know anything about it and what policy says to do. It's designed to answer the singular question of: is this file known? > Some more awkward examples, in case these haven't already been > mentioned in the thread: > > - what about machine code plugins to existing binaries? > > - what about Python modules that aren't executable scripts, but which > are in the import path and might be used by executable scripts? (and > which might modify the import path) > > - what about embedded interpreters? I'm dropping most of /usr/share. So, if it's not in the trust database, its not running. That is safe, but you might have wanted cinnamon to start up. So, this is more about adding back to the trust db that which is needed, but nothing more. Another thing weird I'm finding is there is a lot of matlab and numpy files with execute bits turn on as well as test suites that could be separately packaged. -Steve _______________________________________________ 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
