pyinstaller will not run under fakeroot

[Joachim Metz]

Pyinstaller now seems to have a restriction that it cannot run under root.

"You are running PyInstaller as user root."

1. Can you elaborate what reason for this restriction is? And why this only done for "Unix" not for OSX or Windows?

2. This check is also triggered when running under fakeroot

e.g. from dpkg-buildpackage -r fakeroot

Can you add a flag to override this behavior or fix the detection for root under fakeroot?

[Hartmut Goebel]

Am 19.03.2013 23:00, schrieb Joachim Metz:

Pyinstaller now seems to have a restriction that it cannot run under root.

"You are running PyInstaller as user root."

1. Can you elaborate what reason for this restriction is? And why this only done for "Unix" not for OSX or Windows?

a) PyInstaller does path-manipulation, imports hook-files and other stuff which can be changed by users. This would allow attackers to delete you whole file-system by injecting a malicious module.
b) There is no need for running PyInstaller as root.
c) Root is the super user. One ought not use it for building software.

2. This check is also triggered when running under fakeroot

e.g. from dpkg-buildpackage -r fakeroot

Can you add a flag to override this behavior or fix the detection for root under fakeroot?

No, this would contradict the security measure.

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2012-09-steht-ein-manta-fahrer-vor-der-uni
Blog: http://www.goebel-consult.de/blog/20050620

Goebel Consult ist Mitglied bei http://www.7-it.de/

[Joachim Metz]

> No, this would contradict the security measure.

What security does this change provide?

First of all this restriction does provide very little additional security.

1. You don't protect Windows and OSX for the same attack

2. the attack is still possible in the context of the user account

3. You're preventing a valid use case of running the tooling as fakeroot

4. an attacker could use the same techniques and build something into the resulting binary and compromise far more people

5. Also with Python I'm wondering how easy the check can be monkey patched out

So based on your reasoning and point 4 I would say add something to stop a user from using pyinstaller in the first place ;)

For now I'll need to hack it out. I would appreciate if you change it to give a warning but still allow it to be ignored in the case of fakeroot.

Thanks in advance,

[Hartmut Goebel]

Am 24.03.2013 19:19, schrieb Joachim Metz:

> No, this would contradict the security measure.

What security does this change provide?

Please stop trolling!

Why would one need to run PyInstaller as root?

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-11-in-troja-nichts-neues
Blog: http://www.goebel-consult.de/blog/20060920

[Martin Zibricky]

Joachim Metz píše v Ne 24. 03. 2013 v 11:19 -0700:

> For now I'll need to hack it out. I would appreciate if you change it
> to give a warning but still allow it to be ignored in the case of
> fakeroot.

Could you describe your use case about pretending running pyinstaller as
root?

Do you have a suggestion how to reliably detect that pyinstaller is
running under fakeroot?

[Joachim Metz]

> Why would one need to run PyInstaller as root?

Hartmut, I'm talking about fakeroot. Not running as root. The current check breaks running as fakeroot. Which runs under user context faking root context.

"man fakeroot"

fakeroot  -  run a command in an environment faking root privileges for file manipulation

> Could you describe your use case about pretending running pyinstaller as root? 

Martin, as I said initially I'm running PyInstaller from "dpkg-buildpackage -r fakeroot" this invokes PyInstaller and when building deb files I need to make sure the file privileges of some of the files in the package are correct.

Hartmut, FYI also I'm only jesting (trolling) to a minimal account. The current solution gives a false sense of added security.

My point solve the root cause, do not create a work-around that works for some situations.

I agree that it is good to have the check there, but please change it to warn the hell out of an uninformed user and allow for some means of overwriting it for those edge-cases that the check does not correctly detect.

> Do you have a suggestion how to reliably detect that pyinstaller is running under fakeroot? 

Martin, not at the moment.

[Hartmut Goebel]

Am 25.03.2013 22:32, schrieb Joachim Metz:

> Why would one need to run PyInstaller as root?

Hartmut, I'm talking about fakeroot. Not running as root. The current check breaks running as fakeroot. Which runs under user context faking root context.

So: Why would one need to run PyInstaller as fakeroot?

The current solution gives a false sense of added security.

I disagree. The current solution is one measure. Nobody says this will be "secure".

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-11-in-troja-nichts-neues
Blog: http://www.goebel-consult.de/blog/20060920

[Joachim Metz]

> So: Why would one need to run PyInstaller as fakeroot?

Because it's a tool that offers functionality I would like to use.

> Nobody says this will be "secure".

Correct me if I'm wrong you are the one that referred to it as a security measure

"No, this would contradict the security measure."

> The current solution is one measure.

Can you please elaborate which other "measures" are you using?

Also try this:

create a file named:

usercustomize.py

which contains:

import os

os.setuid(1000)

spawn in to super user

./pyinstaller/pyinstaller.py

"You are running PyInstaller as user root."

As expected.

PYTHONPATH=. ./pyinstaller/pyinstaller.py

Requires at least one script file.

Now, what happened to the "security measure" ?

At least it seems I've found a work-around without having to alter the PyInstaller code ;)

[Hartmut Goebel]

Am 26.03.2013 22:57, schrieb Joachim Metz:

> So: Why would one need to run PyInstaller as fakeroot?

Because it's a tool that offers functionality I would like to use.

Why do you *need* to run PyInstallar as fakeroot?

PyInstaller is a tool for *building*, not for *installing* so I do not see any *need* for running it with more rights than a normal user's one.

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-11-in-troja-nichts-neues
Blog: http://www.goebel-consult.de/blog/20050620

[Joachim Metz]

Hartmut, what is so hard for you to understand about this?

> PyInstaller is a tool for *building*, not for *installing* so I do not see any *need* for running it with more rights than a normal user's one.

1 . "dpkg-buildpackage -r fakeroot" uses fakeroot in the process of building a deb file.

PyInstaller is used in that process to *build*, other parts of the process require fakeroot.

2. fakeroot does not provide more rights than the normal user

(from the man page)

       fakeroot runs a command in an environment wherein it  APPEARS  to  have

       root  privileges  for  file  manipulation.  This is useful for allowing

       users to create archives (tar, ar, .deb etc.) with files in  them  with

       root  permissions/ownership.   Without  fakeroot one would need to have

       root privileges to create the constituent files of  the  archives  with

       the  correct  permissions  and ownership, and then pack them up, or one

       would have to  construct  the  archives  directly,  without  using  the

       archiver.

[Hartmut Goebel]

Am 26.03.2013 22:57, schrieb Joachim Metz:

usercustomize.py

which contains:

import os

os.setuid(1000)

[...]

PYTHONPATH=. ./pyinstaller/pyinstaller.py

You basically did the same as you could do in shell-script:

uname=$(getent passwd 1000 | cut -d: -f1)
su $uname ./pyinstaller/pyinstaller.py

Now, what happened to the "security measure" ?

PyInstaller is not running as root, since you changes the process uid to 1000 then PyInstaller is starting up.

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-11-in-troja-nichts-neues
Blog: http://www.goebel-consult.de/blog/20050620

[Joachim Metz]

Apparently I need to spell it out.

This was largely meant as an example that usercustomize.py can override most of the python interpreter.

A more effective solution (for malicious purposes) would be to wrap the os module and have it return false info.

consider my_os.py

class MyOS(object):

  uid = 1000

  os = None

  def getuid(self):

    return self.uid

  def getrealuid(self):

    return self.os.getuid()

  def __getattr__(self, name):

     if name == 'getuid':

       return self.getuid

     if name == 'getrealuid':

       return self.getrealuid

     return getattr(self.os, name)

And usercustomize.py

import sys

from my_os import MyOS

myos = MyOS()

myos.os = sys.modules['os']

sys.modules['os'] = myos

[Hartmut Goebel]

Am 28.03.2013 10:31, schrieb Joachim Metz:

Apparently I need to spell it out.

This was largely meant as an example that usercustomize.py can override most of the python interpreter.

Yes, and this is one of the reasons why PyInstaller denies running as roof (or fakeroot). Since PyInstaller is changing sys.path to run directly from the download/development directory, an intruder could simply drop in some module there.

Please adopt your build process to not require PyInstaller running as root/fakeroot. As you already showed, there is a simple work-around, there is not need to weaken PyInstaller. (NB: I suggest changing the UID in your build-script instead of hacking arounf with a usercustomize.py. This is more transparent to builder.)

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2011-11-in-troja-nichts-neues
Blog: http://www.goebel-consult.de/blog/20060920

[Joachim Metz]

Ok, thank for your time.

> Yes, and this is one of the reasons why PyInstaller denies running as roof (or fakeroot)

Apparently I cannot convince you that you'll need to find an alternative approach to really solve this issue, instead of slapping on some (more) restrictions.

Since the current restrictions can be easily bypassed I can always use that technique for now.

[Krishna Kamath Koteshwara]

My python scrpit access io port and I am facing the issue. 

Any work around for this ?

if I run as sudo, then I get message saying "125 ERROR: You are running PyInstaller as user root. This is not supported."

But if I run without root, I get "IOError: [Errno 13] Permission denied". 

Any response is highyl appreciated. 

Thanks

[Steve Barnes]

On 27/11/13 21:26, Krishna Kamath Koteshwara wrote:
> My python scrpit access io port and I am facing the issue.
>
> Any work around for this ?
> if I run as sudo, then I get message saying "125 ERROR: You are
> running PyInstaller as user root. This is not supported."
> But if I run without root, I get "IOError: [Errno 13] Permission denied".
>
> Any response is highyl appreciated.
>

Why on earth would your pyinstaller script - which is for building
distribution packages - need to access an io port?

It sounds like you are trying to run pyinstaller within your wider program!

Gadget/Steve

[Eldon Brown]

I'll tell you one very good reason for running Pyinstaller as fakeroot, or in my case under Puppy Linux as "Spot", because in some linux distros running as su or root is the ONLY OPTION. And, before you begin to disparage my chosen OS, Puppy is highly respected among ubergeeks and is slowly being adopted by the lowly "super-users" like me as well. As it stands now, I have to try to uninstall Pyinstaller and that leaves a bad taste in the mouth. Promising application but no good to me with this restriction. What a shame. 

[Hartmut Goebel]

Am 28.05.2014 01:33, schrieb Eldon Brown:

because in some linux distros running as su or root is the ONLY OPTION

So the only user on this systems is root? And there is no normal user-account?

To be frank: If this really is the case, it is plain crap! This is insecure to it's best! And we are not going to support that kind of stuff. So you'd better talk to the Puppy-Linux guys to provide you with a secure system.

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Information Security Management, Security Governance, Secure Software Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/funktioniert-sprachausgabe-inzwischen-brauchbar
Kolumne: http://www.cissp-gefluester.de/2010-07-passwoerter-lieben-lernen

[Joachim Metz]

He this is the default behavior on Windows for years, and you don't have the same restriction there?

What's up with that? Who's being "insecure"?

[Hartmut Goebel]

Am 06.06.2014 06:57, schrieb Joachim Metz:

He this is the default behavior on Windows for years, and you don't have the same restriction there?

What's up with that? Who's being "insecure"?

Yes, this is the behaviour on Windows. But it is insecure, as one can see by all the Malware available for Windows.

We have to support his on Windows, because MS is not able or willed to solve this problem. It is a burden of the past we have to live with. But Unix has a multi-user for decades. If some Linux-Vendors think, it is a good idea to downgrade this, I see no reason why we should support this crap.

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP
Information Security Management, Security Governance, Secure Software Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/eine-millonen-aufkleber-fordern-asyl-fur-snowden
Kolumne: http://www.cissp-gefluester.de/2012-09-steht-ein-manta-fahrer-vor-der-uni

[Joachim Metz]

You could say that and keep complaining about it, in the end not making anything more secure.
Or alternatively accept the fact and solve the security weakness differently.

[Dustin Spicuzza]

For what it's worth, whether it's a good security practice or not, pyinstaller is not the moral police. As a tool, it should just work when users ask it to. Arguably, running as root is stupid -- but using that logic the 'rm' command should have a check to make sure you can't do 'rm -rf /'. However, as many have pointed out, there are some environments where you just can't get away from running as root, whether you want to or not (some embedded environments come to mind).

In particular, docker containers typically run as root, though (as in a fakeroot environment) you don't actually have root privileges. This makes it a bit annoying to use pyinstaller from inside a container (and yes, I could install another user and run it there.. but it's a bunch of extra steps).

Dustin