mysterious files on a fedora system but not from rpm
cs at zip.com.au
Sun Nov 18 22:54:24 UTC 2007
On 18Nov2007 10:20, Dave Burns <tburns at hawaii.edu> wrote:
| > Practically all .py modules will get turned into .pyc files and
| > won't match the manifests.
| So any *.py file may generate a <same name>.pyc file?
Yes, if the interpreter has rights to write to that portion of the
| So if I am trying to be security conscious (anal) and track stuff so I
| can say, "Yeah that belongs there" or "Hey this might be part of a
| rootkit", this makes a big gray area, right?
You can make the same argument about squid caches etc.
Your point is valid though.
| Is there a way I can
| verify that a particular .pyc comes from a .py that *is* on the
I'm not sure. You could write a python script using its "compile()"
function maybe; I don't know how big a step it is from that to a .pyc
| Any way I can request that all .pyc's be constructed *now*
| so I can scan them with tripwire?
One crude approach: remove all the .pyc files. Run a small shell script to
source each python file (using import "modulename" - a lot of modules have
"run a demo/self-test if I am the main program" hooks). Chown root all the
new .pyc files if they're not already so. Run tripwire.
| Some way to deal with this other
| than, "Well, it has the same filename as something that belongs
These are questions I cannot answer. [...snip...]
| > There are also a few dynamicly created configuration and
| > database files floating around Fedora.
| Those would presumably not be executable and seem easier to cope with,
Remember that "data" files, like .pyc files, are in effect "interpreted"
by the tools that use them, because they make decisions based on their
content. For certain data files, a misdfecision can be as subversive as
a trojan .pyc file. Eg a bogus password file with a trojan in the
"shell" column for root (or any other user, such as yourself).
And so forth.
| though I suppose there is still an issue of when can you be sure they
| are all in place? And I suppose that can't be answered in general, but
| must be answered on a case by case basis.
Yeah, I think so. This is why sandboxes are desirable for things you
don't trust. On a UNIX box, special purpose users consitute a kind of
Cameron Simpson <cs at zip.com.au> DoD#743
Microsoft is not the ANSWER.
Microsoft is the QUESTION,
and the ANSWER is NO! - Roland.Giersig at aut.alcatel.at
More information about the fedora-list