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.
On what level do you plan to whitelist---kernel/syscall? shell? all shells?
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. 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@xxxxxxxxxxxxxxxxxxxxxxx
