Re: write with cURL

Tim Greer wrote:
Jerry Stuckle wrote:


To justify $200 worth? Forgive me if I find that suspicious. We're not
talking about a customized service here and security should be done
across all users equally, unless you plan to either allow a specific
user to do more or to lock them down more than someone else (neither
would be appropriate in this case for this example, but neither would
matter, which is the point I was intended to prove). Of course, it's
all for nothing if I'm unable to prove it to you.


Yep. That's a big discount - my normal minimum rate is over twice that. I need to account for the paperwork, etc., also. It takes time to set up an account for you, process the billing, etc.

When everything is considered, it's easily a couple of hours of work - and still a discount from my equivalent hourly rate.

And no, my time is the only thing I have to sell, and I'm not going
to spend the time manually setting up a site without getting paid,
and it's not a $3.95 bargain basement account.
Who said it had to be only $3.95? What about $20 for 5 minutes of
your
time? That's cheaper than the bottom site development price of $200
when you equate the hours spent. The fact is, the development costs
have nothing to do with it. I repeatedly said I'd understand if you
just didn't feel comfortable. You insisted it was because you needed
to use your pricing structure for full site development and hosting
(all just to create a basic account for something that would take a
couple of minutes).

And yes, I do control who has access to my servers.
Obviously.

With my customers
I have a contract, and if they do anything to harm the servers, I
have legal redress.
That's fine, so why didn't you say that before? Why not say that
originally? I could totally understand it. You said that you'd set
up
an account only if I paid you. I said I would. Then it was $200,
and now it's to protect your clients.

Not that any of them would - I pick my customers
carefully, also, and don't let just anyone on the servers.
That's all fine.

And yes, I understand what you explained to me on the phone. But
the first step requires access the users don't have - so the rest of
it is immaterial.
If you think it requires some special access or absolutely anything a
user couldn't do in any type of hosting or shared system environment,
then you didn't understand what I had explained.

Yes, I did understand, and on my servers they can't do step 1. It
doesn't require "special access" - but it does require access they
don't have.

There are ways to do "step 1", but that was just an example of one
method to get there. There are many ways to do the same thing, that
was just one I covered quickly on the phone. Also, what happens when
they upload a binary for the command or use another method (which is
easy enough to do). You then have to try and take further measures to
prevent that. Eventually, you're left without CGI, PHP or SSI, or
otherwise have to run it in a way that no shared host could run.


There is no need to execute binaries on a web site, so I have restricted them from setting the execute bit on a file. Since they can't execute it (if they want to execute a PHP or Perl script, I give them the command to access the interpreter), there's no problem. As well as other ways you can think of.

That's okay, I'm not being paid by you to secure your servers, and
I'm certainly not interested in paying you $200 to help you secure
your own
servers. In fact, I've never said your servers were horribly
secured, and just said that if a user of yours was malicious or had
their account taken over by a malicious user, then the Apache group
idea would open the potential for that malicious user to exploit that
setup to read and write to other people's files.

Sorry, my servers are secure.

No need to apologize. You're welcome to believe it, and that's fine. My offer was to prove to you what you said I was wrong about and your
accusations that I didn't know what *I* was doing.

More is quoted and replied to below.


Nothing you have told me shows me you know how to lock down a server so that it is secure - other than to use the server's file security. There are other ways, but you won't admit to them.

Now, if you know and trust your users, it's unlikely that will be a
risk, provided no malicious users gain access to their account or to
the server in another way. Really, in the end, just saying you're
not comfortable doing it, don't have a server free of non paying
clients you'd feel okay about using, or want to protect yourself in a
legal aspect, then that's fine.

....

On Fri, 2009-02-27 at 21:58 -0500, Jerry Stuckle wrote:
tim@xxxxxxxxxxxxx wrote:
Dear Jerry Stuckle,

Regarding the usenet thread where you've agreed to allow me to prove
that your PHP setup is potentially not secure from user's reading each
other's files using PHP, you've stated that I would have to pay for an
account.
This is fine. Please let me know the price for your lowest priced
shared hosting account and I will promptly remit payment. Please also
let me know the methods of payment avilable (such as paypal, or a
merchant interface).
By accepting this, you agree that I am allowed to test the security
of your PHP install, and cause any damages or access any data that
would be against state or federal laws, and that this is simply to
illustrate that your PHP setup would allow one user on one account to
use PHP to access a file readable by the web server's user/group on
another, seperate account.
Therefore, if you can ensure that you have some test setup with a
temporary user or your own, and not for one of your normal shared
hosting users, that would be best. I remind you that I'm not
interested in accessing any other data or doing anything malicious on
your server, but to example how your PHP setup is not as secure as you
believe it to be.
Thank you,
Tim Greer


Tim,

The problem is, you assume the user has the ability to create a
symlink.

No, that is just one way to get there. And, what happens when someone
uploads a binary for ln (I assume you have it disabled or removed or a
jailed environment where they can't use that system ln command and
don't have it where they can just alias it) and then run it? You plan
to deny execution by not allowing executables? What's the deal then? Are you saying your server is secure because you modify the sites and
the clients don't have access to log in and upload their own or create
their own? If so, then it really doesn't speak in any great amount to
say it's secure because you restrict or don't allow your clients to do
normal and common things. Besides, this does illustrate the point that
if you were a normal shared host that offered clients the ability toe
create symbolic links (and why not in general?), that you would then be
open to that security risk.


Remember - this is WEB hosting. Binary executables are not required on a web site. And no one has requested the ability to upload a binary executable, I would be very leery anyway. Even if I had them in their own jail, I don't know what they might be using the server to do. But I would find out what they want to execute and why - and then make a decision. However, no one has ever asked that, which doesn't surprise me at all.

Since you don't allow symbolic links to be created, you believe the
problem is nonexistent. Two problems exist with that theory. First,
there are other ways (this was just one quick example), and secondly,
more importantly, this wouldn't exist as an issue where users can set
the permissions on their files lower to deny other's from viewing them
or writing to them (symlinks or not). So, this does prove there's a
difference, and a pretty vital one. Surely, if having the ability to
use symbolic links on a server opens such a big security problem, then
you must admit that it's not as secure. If you think it's "as secure"
by removing the ability to do a bunch of things, that's one way to see
the problem, but it's more involved than just having the ability to use
and create symbolic links.


No, I don't say it's a big security problem. But it's not necessary for them to have that privilege.

I never said there is no difference - don't put words in my mouth. I did say that I had secure servers.

You keep trying to tell me ways that the server can be compromised - believe me, I learned about every one of those - over 15 years ago. the difference is I know how to secure a web server without depending on CGI - something you claim is impossible.

But you really don't know.

But that's not possible on my systems - I have ln and certain other commands restricted so they can't be used.

Doesn't matter though. Obviously different systems can try different
things to achieve the same results regarding security, but at some
point, sometimes one of those methods is less secure and less
desirable. Again, your method is better than world write, but it's not
as secure as suPHP. There's nothing wrong with realizing or seeing
that. Perhaps you can manage to really take away a bunch of common
commands and features and hope no one could easily get around them (and
they can so long as you allow CGI and PHP since they don't have to use
"ln") and you have the same problem anyway. That just doesn't sound
like a good, sound balance to me.


Yep, and running PHP as a CGI is less desirable. And you can claim it's less secure than suPHP, but you really don't know - because you are making assumptions about my security that you don't know. Or, you are just saying anything not done YOUR way is not as secure.

You really don't know, Tim. You don't know my capabilities; you don't know my system; you don't know my security setup. So you really can't say it's less secure.

So your idea of using a symlink to map the directory into the user's
web
space doesn't work.

But it does. You're saying it doesn't, because the users can't create a
symlink, but what if they could? They can still do it, after all. However, let's just forget entirely about that one single example I
quickly rattled off about, since it was just one of many ways to get to
that point.


What if pigs could fly? They can't, so any further discussion on the point moot.

There is no need for a user to be able to create a symlink on the
system
for a website; if they absolutely need one and can justify it, I'll do it for them. But no one has had a good reason why they need to do it.

Sure, there are plenty of reasons. Not having duplicate files that all
serve up the same data. Moving sites around without having to
duplicate the content or use rewrite or redirect rules, or a ton of
other reasons. But, I remind you, this isn't about symbolic links and
that was one example.


They don't need symlinks to do that. And sites can easily be moved - to a different directory, different server or even a different domain - with no changes in the code, if it's written properly. NONE of my code is EVER dependent on any of those.

<snip. you have a strange way of quoting in this thread>

Actually, I DON'T trust my users - any more than anyone else. But at
least with a contract I have legal recourse against them should they
do anything harmful.

That doesn't have anything to do with the problem when someone with ill
intent gains access to your client's account, or that you can't know
all of your clients that well if you are very successful.


You're the one who claimed I trusted my users. I never did.

And even if someone gains access to my client's account, the client is still liable (unless he can prove negligence on my part - which he can't).

What is not immaterial is all of your previous claims and
accusations, going as far to say I said things I never said, meant
things I never meant, and so say I'm not a competent server admin
regarding security issues, all because you didn't agree with me (all
before we even
discussed what I was talking about). Your method is better than the
need for world write, I said that myself, and I didn't reply to
attack or embarrass you.

You are assuming everyone can do step 1. It can be restricted, quite
easily. And it is, on my systems.

I believe I replied to that misconception above, already.

In fact, my replies only come from the need to defend myself from
untrue accusations (all based on the fact you didn't agree, and you
attacked
me for it). So, coming to this final conclusion by calling your
bluff,
is hardly immaterial, and your clients could do these things. However, this is certainly and obviously not going to go anywhere and
it won't progress, so I have left the offer open to you if you ever
want me to show you (even for a price -- but not for $200, you have
to be realistic and reasonable, else it smacks of an excuse), as well
as the
offer for others using the same type of setup as you. Beyond that, I
suppose we can drop the subject. I'm willing to, if you are (that
is, at this point, I'm just replying to the posts).
I don't agree because it's not true.

Yet you won't allow anyone to prove otherwise, which is pointless. Don't accept or make a challenge and start running your mouth (or
keyboard) making claims and accusations, egging someone on, only to
back down when they call your bluff.


No, I'm not going to waste my time.

And it takes about 45 minutes to an hour to set the account up - just because I don't do it very often.

Any good sys admin would create a script to do this for them if they it
more than once and it takes that long. I don't believe you, but I
can't prove you are just making excuses, but you can understand why I'd
think it.


As I said - I don't do it often enough to make it worthwhile creating a script. There is a time to write scripts - and a time to NOT write scripts. Part of being successful is knowing the difference.

And I have tests that I perform to ensure security before anyone is
allowed on the system - just to make sure *I* didn't miss anything.

Yeah, sure. Keep backpeddling.

Nope. Not here.
Among other things, the test do try to do step 1 in your scenario

Something you didn't understand or try, or you did and saw it worked and
just don't want to admit it (and even claim you don't allow symlinks,
which is ridiculous -- a very poor way to tackle that security
problem). This is why I said instead of relying on PHP settings and
such things to take and make up for the lack of a good security basis,
that it is better to go with the better foundation. Otherwise, well,
you'd be in your shoes.


No, you won't admit that you might be wrong, and there ARE other ways to secure a web server that you're not aware of.

(yes, I'm familiar with it - just didn't want to get into an argument
on the phone), and fail if they can do it.

Yeah, sure you're familiar with it (or were already). Whatever, Jerry. I know for a fact that because of the Apache web server design, that
any file that can be read by the web server without changing users,
will be able to be read or written to globally. There's no way around
it, because that's the way Apache is designed (and it's not just Apache
either, by the way, but since this is what the OP's host uses, as well
as both of us, it was relevant to the example). Really, get past the
symlink aspect, because that was one pretty trivial example.


Sure - somewhere around 15 years ago or more, as I said before. I've been involved in Unix administration for a LONG time - close to 20 years.

Again, there's no point in you repeating what will or will not work, or
you insisting your server is secure or not from this, since you refuse
to allow me to show you on your system (and as I suspected, you would
just claim it doesn't work (though it's ironic you claim so based on
the fact that ln is disabled from your clients using it), just like I
suspected and called you on the excuse that it would be some
unreasonably large amount of money for you to set me up -- I called
that as likely to happen before I even called you.) Really, enough
already. You know I've proven my point, regardless of what you say or
believe and that is why you grasped for multiple reasons of why you
actually couldn't let me prove it to you. So, whatever, Jerry. Nothing's going to change, and I'm just having to repeat myself (if you
don't listen or want to argue about it the first dozen times, there's
no reason why anything's going to change). So, let's just move on from
this topic and call it done.

And there's no point in trying to convince you that your way is NOT the only way to secure a server. Some people are not willing to admit they don't know something.

Remember - I'm not the one who said YOUR servers are not secure. But you keep repeating that my servers are not secure - despite not knowing how I have my security set up. Nice crystal ball you have there, Tim.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.