Re: [IronPython] Default install location and site-packages

[Jeff Hardy]

On Tue, Oct 6, 2009 at 11:53 AM, Giles Thomas
 wrote:
> Michael Foord wrote:
>>
>> (I'm honestly not sure how creating a writable directory is a security
>> issue?)
>
> I suspect people are thinking of an attack where an untrusted user installs
> a package that looks like a normal one, but actually does something
> nefarious like install a rootkit (and perhaps does what the package is meant
> to do as well).  If the administrator then uses the package, the machine is
> compromised.

Exactly. And Python doesn't have codesigning or such to prevent such an attack.

For desktops it might not seem like a big deal, but for servers it's
an absolute disaster. It's better if it's not even possible.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Giles Thomas]

Michael Foord wrote:
(I'm honestly not sure how creating a writable directory is a security 
issue?) 
I suspect people are thinking of an attack where an untrusted user 
installs a package that looks like a normal one, but actually does 
something nefarious like install a rootkit (and perhaps does what the 
package is meant to do as well).  If the administrator then uses the 
package, the machine is compromised.



Cheers,

Giles

--
Giles Thomas
giles.tho...@resolversystems.com
+44 (0) 20 7253 6372

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Giles Thomas wrote:

Dino Viehland wrote:

But it seems like CPython is the one who's doing something wrong here.
  
Another data point; easy_install under CPython using Vista with UAC 
switched on tries to escalate permissions as you would expect -- the 
normal grey screen, "please enter an administrator's details" thing -- 
and then happily installs the egg under C:\PythonXX\lib\site-packages, 
owned by Administrator, with no read permissions for anyone else.  So 
you then have to go and find it and manually change the permissions if 
you want to use it.


Somewhat orthogonal, but it does make it sound rather like the setup 
with CPython is accidental rather than by deliberate choice.




I doubt it can be accidental - I think the changed permissions would 
have to be done deliberately in the installer?


Historically Windows has made much less of a distinction between user 
and system installed programs. On the Mac I need to sudo to install into 
my *system* site-packages but not into the site-packages of a user 
installed version of Python.


I still see it as a question of usability rather than security. (I'm 
honestly not sure how creating a writable directory is a security 
issue?) If the default install location of IronPython makes installing 
and using Python packages with IronPython impossible for non-elevated 
users then that is an extreme misfeature.


Michael



Cheers,

Giles




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Giles Thomas]

Dino Viehland wrote:

But it seems like CPython is the one who's doing something wrong here.
  
Another data point; easy_install under CPython using Vista with UAC 
switched on tries to escalate permissions as you would expect -- the 
normal grey screen, "please enter an administrator's details" thing -- 
and then happily installs the egg under C:\PythonXX\lib\site-packages, 
owned by Administrator, with no read permissions for anyone else.  So 
you then have to go and find it and manually change the permissions if 
you want to use it.


Somewhat orthogonal, but it does make it sound rather like the setup 
with CPython is accidental rather than by deliberate choice.



Cheers,

Giles

--
Giles Thomas
giles.tho...@resolversystems.com
+44 (0) 20 7253 6372

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> Dino Viehland wrote:
> > Michael wrote:
> >
> >> Curt Hagenlocher wrote:
> >>
> >>> In principle, allowing unprivileged users to install code into a
> >>> location where it can unknowingly be accessed by privileged users is a
> >>> security problem. A "per-user" approach is the right one.
> >>>
> >> Unknowingly?
> >>
> >
> > I've just installed some software.  Installing that software required that
> > I elevate to admin and left that software in a typically global location
> > on my machine (either C:\... or C:\Program Files\...) where my normal user
> > account does not have writes to access.
> >
> > What's the least surprising - that the global location is now suddenly
> > writable or that the global location remains writable only be
> > administrators?
> >
> 
> Your answer seems orthogonal to the question I asked.
> 
> As you answered my question with a question perhaps I can do the same:
> 
> A user has an installed version of Python and an installed version of
> IronPython. He wishes to install a library for both IronPython and
> Python so he runs:
> 
> python setup.py install
> ipy.exe setup.py install
> 
> The first succeeds, naturally. Are you saying that it would be *more*
> surprising if the second succeeded?
> 
> Unfortunately at the moment it fails silently, but an "access denied"
> error would not be much more helpful.

My point is simply that if a user is surprised by the fact that we've created
a globally writable place that effects the code they're running then they have
unknowingly done this.  Or another way to put this is any decision which leads 
to less security shouldn't ever be a surprise to the user.

I'll agree that the difference between CPython and IronPython may be 
surprising to someone who is used to CPython.  But it seems like CPython is
the one who's doing something wrong here.  I just checked on a Linux machine
and there CPython is behaving like we are:

di...@sh0:/usr/lib/python2.5/site-packages$ ls
apt  aptsources  python-support.pth
apt_inst.so  debconf.py  README
apt_pkg.so   python_apt-0.6.17.egg-info  unattended_upgrades-0.1.egg-info
di...@sh0:/usr/lib/python2.5/site-packages$ cp apt_inst.so xx
cp: cannot create regular file `xx': Permission denied
di...@sh0:/usr/lib/python2.5/site-packages$


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Jeff Hardy wrote:

On Tue, Oct 6, 2009 at 10:53 AM, Michael Foord
 wrote:
  

The first succeeds, naturally. Are you saying that it would be *more*
surprising if the second succeeded?



It should be surprising - a limited user should *never* be able to
install software into a shared location. The fact that it works for
CPython is a bug, not a feature. I would totally expect to have to
elevate to install a package; IIRC, it's the norm on *nix machines to
need to sudo to write to site-packages.
  


You can try raising a bug against CPython for this, but I *imagine* you 
will get short-shrift (although in the presence of PEP 370 I am willing 
to be surprised).


So the question is, how important is CPython compatibility in regard to 
this behaviour?


Perhaps IronPython could make PEP 370 site-packages the *default*?

Michael


Limited users should only be able to write to a per-user site-packages
(I think this is what virtualenv is supposed to accomplish, but
virtualenv has always been a mystery to me). It's no different that a
limited user being able to install into the GAC.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Jeff Hardy]

On Tue, Oct 6, 2009 at 10:53 AM, Michael Foord
 wrote:
> The first succeeds, naturally. Are you saying that it would be *more*
> surprising if the second succeeded?

It should be surprising - a limited user should *never* be able to
install software into a shared location. The fact that it works for
CPython is a bug, not a feature. I would totally expect to have to
elevate to install a package; IIRC, it's the norm on *nix machines to
need to sudo to write to site-packages.

Limited users should only be able to write to a per-user site-packages
(I think this is what virtualenv is supposed to accomplish, but
virtualenv has always been a mystery to me). It's no different that a
limited user being able to install into the GAC.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Dino Viehland wrote:

Michael wrote:
  

Curt Hagenlocher wrote:


In principle, allowing unprivileged users to install code into a
location where it can unknowingly be accessed by privileged users is a
security problem. A "per-user" approach is the right one.
  

Unknowingly?



I've just installed some software.  Installing that software required that
I elevate to admin and left that software in a typically global location
on my machine (either C:\... or C:\Program Files\...) where my normal user 
account does not have writes to access.  


What's the least surprising - that the global location is now suddenly
writable or that the global location remains writable only be 
administrators?


  


As a user I probably don't care (and won't even check) whether a 
sub-folder in the install location is now writable. What I *do* care 
about is whether that software *works* - and an access denied error on 
using aspects of that software *will* 'surprise' me, yes. :-)


Another way of phrasing the question - does writability of a sub-folder 
in the IronPython install folder *trump* compatibility with CPython 
behaviour?


Michael



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Dino Viehland wrote:

Michael wrote:
  

I don't have an obvious solution (per user site-packages perhaps?) but
present the problem. Python circumvents this problem by *not* installing
into "Program Files".



I would actually say that CPython seems to circumvent this by allowing
users to write to its installation directory.  Interestingly it does not 
allow modifying the existing files (e.g. I can't modify site.py w/ out

elevating to admin, just as I can't create files at C:\ w/o elevating
to admin).
  


Ignoring for the moment that distutils doesn't work yet, it seems to me 
to be a "bug" (or at the very least a problem) that a normal user can't 
install packages into their standard installation.


If Python libraries write or modify files in their package directory 
then elevating on install wouldn't be enough - elevation would be 
required to use them. I don't have any metrics on how common that is, 
but my guess would be "not uncommon".


Does IronPython implement PEP 370?

   http://www.python.org/dev/peps/pep-0370/


Michael



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Dino Viehland wrote:

Michael wrote:
  

Curt Hagenlocher wrote:


In principle, allowing unprivileged users to install code into a
location where it can unknowingly be accessed by privileged users is a
security problem. A "per-user" approach is the right one.
  

Unknowingly?



I've just installed some software.  Installing that software required that
I elevate to admin and left that software in a typically global location
on my machine (either C:\... or C:\Program Files\...) where my normal user 
account does not have writes to access.  


What's the least surprising - that the global location is now suddenly
writable or that the global location remains writable only be 
administrators?
  


Your answer seems orthogonal to the question I asked.

As you answered my question with a question perhaps I can do the same:

A user has an installed version of Python and an installed version of 
IronPython. He wishes to install a library for both IronPython and 
Python so he runs:


   python setup.py install
   ipy.exe setup.py install

The first succeeds, naturally. Are you saying that it would be *more* 
surprising if the second succeeded?


Unfortunately at the moment it fails silently, but an "access denied" 
error would not be much more helpful.


All the best,

Michael



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> Curt Hagenlocher wrote:
> > In principle, allowing unprivileged users to install code into a
> > location where it can unknowingly be accessed by privileged users is a
> > security problem. A "per-user" approach is the right one.
> 
> Unknowingly?

I've just installed some software.  Installing that software required that
I elevate to admin and left that software in a typically global location
on my machine (either C:\... or C:\Program Files\...) where my normal user 
account does not have writes to access.  

What's the least surprising - that the global location is now suddenly
writable or that the global location remains writable only be 
administrators?



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Dino Viehland]

Michael wrote:
> I don't have an obvious solution (per user site-packages perhaps?) but
> present the problem. Python circumvents this problem by *not* installing
> into "Program Files".

I would actually say that CPython seems to circumvent this by allowing
users to write to its installation directory.  Interestingly it does not 
allow modifying the existing files (e.g. I can't modify site.py w/ out
elevating to admin, just as I can't create files at C:\ w/o elevating
to admin).


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Michael Foord]

Curt Hagenlocher wrote:
In principle, allowing unprivileged users to install code into a 
location where it can unknowingly be accessed by privileged users is a 
security problem. A "per-user" approach is the right one.


Unknowingly?

Michael



On Tue, Oct 6, 2009 at 4:45 AM, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Hello guys,

The msi installer installs by default into "C:\Program
Files\IronPython 2.6". It also creates a "Lib\site-packages" folder.

Presumably the intention is that site-packages is for installed
modules / packages, however "Program Files" is a special location
and normal users (Vista / Windows 7) *can't* create files there.
This means that distutils *must* be run with elevated permissions
to install into this location.

It doesn't work anyway because distutils attempts to
bytecode-compile, which unsurprisingly fails with IronPython - but
that bug in distutils will be fixed shortly.

I don't have an obvious solution (per user site-packages perhaps?)
but present the problem. Python circumvents this problem by *not*
installing into "Program Files".

All the best,

Michael

-- 
http://www.ironpythoninaction.com/


___
Users mailing list
Users@lists.ironpython.com 
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Curt Hagenlocher]

In principle, allowing unprivileged users to install code into a location
where it can unknowingly be accessed by privileged users is a security
problem. A "per-user" approach is the right one.

On Tue, Oct 6, 2009 at 4:45 AM, Michael Foord wrote:

> Hello guys,
>
> The msi installer installs by default into "C:\Program Files\IronPython
> 2.6". It also creates a "Lib\site-packages" folder.
>
> Presumably the intention is that site-packages is for installed modules /
> packages, however "Program Files" is a special location and normal users
> (Vista / Windows 7) *can't* create files there. This means that distutils
> *must* be run with elevated permissions to install into this location.
>
> It doesn't work anyway because distutils attempts to bytecode-compile,
> which unsurprisingly fails with IronPython - but that bug in distutils will
> be fixed shortly.
>
> I don't have an obvious solution (per user site-packages perhaps?) but
> present the problem. Python circumvents this problem by *not* installing
> into "Program Files".
>
> All the best,
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Default install location and site-packages

[Brian Curtin]

On Tue, Oct 6, 2009 at 06:45, Michael Foord wrote:

> Hello guys,
>
> The msi installer installs by default into "C:\Program Files\IronPython
> 2.6". It also creates a "Lib\site-packages" folder.
>
> Presumably the intention is that site-packages is for installed modules /
> packages, however "Program Files" is a special location and normal users
> (Vista / Windows 7) *can't* create files there. This means that distutils
> *must* be run with elevated permissions to install into this location.
>
> It doesn't work anyway because distutils attempts to bytecode-compile,
> which unsurprisingly fails with IronPython - but that bug in distutils will
> be fixed shortly.
>
> I don't have an obvious solution (per user site-packages perhaps?) but
> present the problem. Python circumvents this problem by *not* installing
> into "Program Files".
>
> All the best,
>
> Michael
>  
>

FWIW, the first time I installed IronPython via MSI I just clicked through
the installer without looking and was surprised to see that it went to
Program Files (user error, I know). I actually had to do a file search to
find it because, out of habit, I was expecting it at C:\IronPython.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com