On Tue, 2005-06-21 at 13:20 -0400, Peter Jones wrote: > On Tue, 2005-06-21 at 13:06 +0200, Tomas Mraz wrote: > > > More (much more?) work for little gain, but likely the correct solution > > > would be to configure SELinux policy to recognize a python program > > > trying to write a pyo file and allow that to pass. (Coupled with % > > > ghosting.) > > > > No, that wouldn't be secure. The written .pyo file could be arbitrary > > code which if run again for example from a different security context > > could exploit your system even more. > > Just to be sure, is this really a problem at all? We're not shipping > python set up to generate the .pyc and .pyo files by default, AFAIK, > we're merely making rpm run the .pyc's through python -O. > > So if you log in as root and run some random python program that has a > bunch of .py's in /usr/lib/python2.4/site-packages/, that shouldn't be > generating .pyc's and .pyo's. > > This is _just_ /usr/lib/rpm/brp-redhat running brp-python-bytecompile, > which in turn uses python -O to make .pyc's. It's not something at > runtime. I think Tomas's observation is correct. The python interpreter we ship does attempt to generate .pyc files when it executes a .py file if its non-existent or out of date. It can be a security issue if the .pyc or .pyo file is malicious. It might be malicious if the .py file was malicious, but that is less likely since .py files are installed by root. However, if you allow any user/process to write a .pyo file for later execution you do expose yourself malicious intent via a .pyc or .pyo which is not derived from the source .py. -- John Dennis <jdennis@xxxxxxxxxx>
