On Fri, May 22, 2020 at 3:20 PM David Malcolm <dmalcolm@xxxxxxxxxx> wrote: > Hi Steve > > 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. > > 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? 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?) And perhaps re-inventing SELinux, applying sophisticated whitelists and permissions on components throughout userland, is so complex and error-prone that people will turn it off immediately simply so it's out of their way, and it will break working software at difficult to preduct moments? I'm leery of familiar technological approaches that have been tried, and been discarded as a matter of course, so repeatedly. Would the time be better spent enhancing SELinux? That's not a big business opportunity, but it might be considerably more useful than another whitelisting tool that requites tuning nad management. > 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 example scripts in /usr/share/doc/ ? This seems like a case of "premature optimization".: if you're going to manage privileges for binaries, you're going to have to enter /usr/share/, despite the FHS. > - what about embedded interpreters? > > Hope this is constructive > Dave > _______________________________________________ > 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 _______________________________________________ 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
