User security worries again


#1

I find a new shell user can freely read the website files of an existing user on the same plan, despite the Panel’s “Add User” saying:

Please know that new users cannot access the files/folders of existing users!

Just me? Or do others find this too?


#2

Yup, don’t see how this could be true unless they changed the default group and permissions on home directories. I haven’t created a user in a while, but it is well known that:

  1. Users on a plan belong to the same group
  2. The default permissions on directories (ie 755), including home directories (751), allows group read/execute.
  3. The default permissions on “web site files” allows group read for data files (ie 644), and both group read/execute for executables (ie 755).

:cool: Perl / MySQL / HTML CSS


#3

Ah, today I see the word “access” has changed to “edit”:

Please know that new users cannot edit the files/folders of existing users!

So I take it they /can/ access :frowning:


#4

They can’t access your files if you don’t let them – you do control this, after all.

If you don’t want other users in your group (i.e., the other users you set up) from possibly reading the files in your user directory, you can change the permissions on your files (and the defaults on your FTP client, preferably) so that by default only the owner (you) can write OR read the files you want to keep private.

The files that you want Apache to serve directly need to be readable by ‘other’… but you can chmod 600 *.php – set your PHP files to be readable only by you – as long as you’re using the default PHP setup and running it as a CGI, as your user.

HTH.


#5

For the record, I absolutely agree that DH should update the docs. They need to be clear that without extra steps, your other users can’t edit, but they CAN “access” your files – reading them, downloading them, etc…


#6

[quote]They can’t access your files if you don’t let them – you do control this, after all.

[/quote]

OK, what’s the best way to upload a file such that no-one else gets access?

[quote]you can chmod 600 *.php – set your PHP files to be readable only by you

[/quote]

Taking care that the files don’t exist for any time before the chmod…


#7

This depends on your SFTP client – I use SecureFX (vandyke.com), which is non-free, but which has a setting to control the initial permissions on files and directories I upload. I don’t know what other clients offer this feature, but I know many don’t.


#8

I forgot that of course the OS lets you set the default for files/dirs you create… I didn’t know the details, but that’s what Google is for (and by now I wanted to know myself).

What you want is the umask command. In your case, probably umask 077 – that will make default privs on files rw------- and defaults on directories rwx------.

To apply this to your shell logins, put that command in your .bash_profile, for FTP put it in your .bashrc file. These are in your home directory.

You can still change permissions on individual directories and files so that others (i.e., Apache) can access them as needed.

Warning – this is a little tricky, though; a directory that’s not executable to “other” means that Apache also can’t access any subdirectories in any way, regardless of file permissions. It might be easier to go with umask 066; this makes all directories executable by everyone (which means they can get a directory listing and can access subdirectories… but they’re still limited by the file permissions so they can’t read any file).


#9

Don’t forget that you have the ability to add groups for your users. You can, for instance, create a group for svn (say fidosvn for a site fido.com) and add users you want to allow svn access to it. You’ll have to ‘chgrp’ the svn repository and maybe the binaries if you built them yourself. Adding groups and users to groups can be done on the panel.


#10

OK, your saying that “new users cannot access the files/folders of existing users” cannot be acheived, without breaking web service, or leaving loopholes… true?


#11

I’m all confused here–can someone explain how exactly they’ve been able to access files belonging to other users? I’ve logged in and played around with ftp & ssh with the three user accounts under my plan (since I have the passwords to all three accounts), and in each case I can’t see the other users’ files, just the files in the user’s home directory (and web directory where that’s relevant). What am I missing?

It’s not a problem for me right now, but in a month or so I’m going to be setting up some web space for someone who I don’t want to have access to the files in my home directory.


#12

[quote]can someone explain how exactly they’ve been able to access files belonging to other users?

[/quote]

I just log in as a shell user and enter e.g.

dir …/…

to see a list of users. Pick a user and enter e.g.

dir …/…/aacc/aaccenter.com

to see a load of user aacc’s folders or

cat …/…/aacc/logs/aaccenter.com/http/access.log

to read one of his log files.


#13

It seems to me like the umask solution (and just making selected static files available for Apache) would solve your privacy problem. Unless you’re serving pages up to the public internet that you don’t want the users in your group to see – which seems pretty backwards.

Honestly, there may also be an alternative to giving Apache read access to these files; there’s still plenty I don’t know about this stuff. But I suspect Apache runs as the “nobody” user intentionally – so that if you don’t want it handing out your files to the outside world, it won’t happen by accident.


#14

[quote]It seems to me like the umask solution (and just making selected static files available for Apache)
would solve your privacy problem.

[/quote]

No, because you said it would expose folder names.

If you or anyone can tell me how/if “new users cannot access the files/folders of existing users” can actually be acheived, I’d be grateful.

[quote]Unless you’re serving pages up to the public internet that you
don’t want the users in your group to see – which seems pretty backwards.

[/quote]

It is not as simple as that. Shell access risks exposures that HTTP does not e.g. association between site and username and site and site.


#15

Sorry; I assumed you weren’t keeping private info in your directory names (seriously, is this a discussion of your actual requirements, or just an exhaustive exploration of a DreamHost claim?). You can certainly deny others from getting a directory listing or seeing your file structure – that’s what the “executable” permission on directories is for (reread my notes on umask settings above… umask 077 is what you want). I just suggested leaving that alone because it’s easy to cause yourself problems if you forget which folder is set how… and for “other” (like Apache) to access anything in a given folder, it needs ‘x’ access to all parent folders. It’s like most computer security; you trade off convenience for security.

Meaning that other users on the same server can associate your username with your website? And figure out that you run sites X, Y & Z? Well, this is likewise avoidable; for site superduper.com, create the user superduper, put them in group superduper, and give the site to that user. Repeat with other sites. Don’t forget you’re legally required to use accurate info in your domain registration – that’s probably an easier way to link your sites, if someone wants to.

But more importantly – if this is a serious concern, you are not a good candidate for shared hosting. Get a VPS or dedicated server somewhere. The Dreamhost servers are quite secure compared to many other shared hosting solutions – there are plenty of hosts where you can’t run PHP as CGI without a special request… which means that almost everyone has plenty of files that anybody on the server can write. Is that dangerous? Not really, if you’re just hosting baby pics and a blog. Another user doesn’t want to lose their own hosting and possibly face legal trouble just to photoshop a funny face on your baby. But if you’re hosting sensitive data, and operating sensitive sites on shared hosting, you’re in the wrong place… Partly just because if you get your permissions wrong, your sensitive data is readable by strangers.


#16

[quote]Sorry; I assumed you weren’t keeping private info in your directory names

[/quote]

No need to make risky assuptions if we stick to “new users cannot access the files/folders of existing users”.

[quote]or just an exhaustive exploration of a DreamHost claim?).

[/quote]

I’m not interested in Dreamhost’s claim, expecially since they’ve retracted it. I’m simply interested in what level of security can be reasonably relied on. Without little loopholes like “OK, they can see your folder names” which in my experience often lead to unforseen issues.

[quote]You can certainly deny others from getting a directory listing or seeing your file

[/quote]

But only by pranging web service. Thanks for the explanation.

[quote]It’s like most computer security; you trade off convenience for security.

[/quote]

Well, we haven’t yet found /any/ convenience trade-off that gives security from other peeking e.g. my web log files.

[quote]if this is a serious concern, you are not a good candidate for shared hosting.

[/quote]

I can make that decision… but only from a position of being informed. Hence my questions about the original misinformation and now lack of information.


#17

Hey, come on now. I don’t work here, you know. Everything I’ve typed up for you adds up to nothing but a “lack of information”? Ouch.

As far as I can tell, I’ve given you a solution for everything you asked about except (and I’m not researching this one) the Apache logs. Ask support about it.

Plus, it seems like access to other users may be more locked down than it seems; I tried getting directory listings from other users on my server – even though directories are executable to “other”, I couldn’t get a directory listing.


#18

Your help is appreciated. I’m reluctant to start applying duct tape to a sieve before understanding where the bucket disappeared to. You’ve armed me well with tape - the lack of information I refer to is w.r.t. the bucket.

And on that subject of customer expectations, I think there’s a big gap between your “just hosting baby pics and a blog” for which shared is OK, and an $1000pa Strictly Business plan for which shared is being used.

Yes I asked Support about logs. No reply yet.

[quote]Plus, it seems like access to other users may be more locked down than it seems; I tried getting
directory listings from other users on my server – I couldn’t get a directory listing.

[/quote]

Nor I. But I can get sub-directory listings. Excepting Maildir thankfully!

[quote]even though directories are executable to “other”,

[/quote]

Has “unexecutable to group” taken priority in your case? Else how is that possible under Linux?