On Fri, 22 May 2020 at 15:20, David Malcolm <dmalcolm@xxxxxxxxxx> wrote:
On Fri, 2020-05-22 at 10:30 -0400, Steve Grubb wrote:
> Hello,
>
> I am working on our application whitelisting daemon. 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.
>
...
> Best Regards,
> -Steve
>
>
> 1 - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
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.
For various security audits.. it actually isn't in the weeds. The general want will be that everything that could be executable is known and in places that are easily checked/removed by say a Private First Class without much training but a book that says rm -rf /usr/share-execs/. IN most cases it is more the ability to say that these files can be also checked by various tools
And yes this does mean the removal/audit etc of
pdf/postscript
bash scripts
python/perl/etc
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?)
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?
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
Stephen J Smoogen.
_______________________________________________ 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
