I thought a DROP BOX was write only!

lurk said:
Huh? Only the most restricted accounts using the simple finder would not have access. All standard accounts can use it just fine.

Ok, to rephrase that - on my network, non-admin users will not have access to the terminal app unless otherwise approved by me. :D

* it does not require using simple finder - this can be done using the "some limits" panel under Limitations in Accounts .
 
OK, well I won't tell you about all the other ways to get a shell on a Mac, don't want you to get ulcers or anything worrying about them. The terminal is just is most direct way. If you really think that you are doing anything to improve security by doing that you are sadly mistaken. All you are doing is inconveniencing your users. It may be a nice power trip but it doesn't actually accomplish anything.

What is the real problem you are trying to address? There is most likely a right way to address it (and just so you know what you described isn't the right way.)
 
Actually i am very interested in these "other ways" , please tell me about them - but please also answer this question for me: if the user is on a mac that does not even have terminal.app installed, and cannot d/l or install it, how can they get a shell?

lurk said:
OK, well I won't tell you about all the other ways to get a shell on a Mac, don't want you to get ulcers or anything worrying about them. The terminal is just is most direct way. If you really think that you are doing anything to improve security by doing that you are sadly mistaken. All you are doing is inconveniencing your users. It may be a nice power trip but it doesn't actually accomplish anything.

What is the real problem you are trying to address? There is most likely a right way to address it (and just so you know what you described isn't the right way.)

All you are doing is inconveniencing your users
Working in hospitals, i have had access to many corporate networks over the years and none of them allowed non-admin users access to things like DOS-prompts,command-line, or any other similar features that could be used to breach security.
 
Well, there's the "do shell script" instruction in AppleScript, for one. I'm sure there are plenty of other ways to launch a process, too.
 
well, ok - but can you write an applescript* that will cd to another users directory, give you sudo priviledges, find interesting files, and then allow you to read these files?
AND cover your tracks so no one will know what you have done? ::evil::

* applescript can be disabled in the limitations panel


( a "do shell script" will not give you interactive
command-line access, will it?)
 
g/re/p said:
give you sudo priviledges,

No, but you wouldn't be able to do that from the Terminal either without proper access privileges.

Oh, and it completely slipped my mind how easy it is to get to a shell:

1. Logout
2. Enter the username ">console", with no password, and hit enter
3. Login
4. Fun

Or just reboot the machine, hold Command-S, and get instant root access.

The Terminal application is NOT the security hole, in other words. ;-)
 
Setting the open firmware password would deny access to >console or booting into single-user mode. (yes , there are
programs that hack the open firmware password, but they can only be used in an account that allows you to install them)

davidbrit2 said:
No, but you wouldn't be able to do that from the Terminal either without proper access privileges.

Oh, and it completely slipped my mind how easy it is to get to a shell:

1. Logout
2. Enter the username ">console", with no password, and hit enter
3. Login
4. Fun

Or just reboot the machine, hold Command-S, and get instant root access.

The Terminal application is NOT the security hole, in other words. ;-)
 
g/re/p - really, the terminal is not the problem. It's just a way to run programs, like any other way; there are many.

Anyway, the fact that you couldn't 'go to folder' in the Finder is not the issue - you can't read the contents of someone else's dropbox in the terminal either. That's what the directory permissions are for.

The deal is - you can't list the directory contents of the drop box, but if you already know something that's in there you can read it, or overwrite it with a file of your own. This goes whether you have access to the terminal or not. All operations in someone else's drop box are blind, no matter how you execute them - Terminal, Finder, something else... All operations are dictated by directory permissions only.

Want to overwrite a file in someone else's drop box? Make an identically named file, drag & drop. Want to read a file in someone else's drop box? Type the URL into the address bar in Safari: file:///Volumes/Mephistophilis/Users/ami/Public/Drop%20Box/bar does it for me

Can you use sudo to change user IDs and hide your actions? Only if you're in /etc/sudoers, which is equivalent in OS X to being an administrator - so your non-admin users couldn't use sudo even it they could use the Terminal, and your admin users can just un-limit their accounts to let themselves use Terminal.app.

As for setting the sticky bit - chmod +t Drop\ Box will do it. See also the manpage for "sticky" to read the exact description of what the sticky bit does in OS X. Note that there is no obvious non-terminal way to do this in OS X. Denying your users terminal reduces the security of the knowledgeable ones (those who aren't willing to break policy and bring in their own copy of Terminal, or some similar way of bypassing OS X's silly, useless 'limited accounts')
 
Are you sure that setting an OF password will restrict access to >console logins? I'm not so sure - OF only controls boot options, I had thought. Logging in as >console is done after the OS has booted, by which time OF is out of the way.
 
scruffy said:
Are you sure that setting an OF password will restrict access to >console logins? I'm not so sure - OF only controls boot options, I had thought. Logging in as >console is done after the OS has booted, by which time OF is out of the way.


/me smacks himself :confused:
 
Grep there have been several ways mentioned for getting a shell and there are even more. It is not worth listing them though because the reality is that OSX is *nix and shells are just integral to the way things work. Programs that you don't even think of as having shells run them all the time.

If you want to actually make the system secure you need to do it with the assumption that the user has shell access. So just stick the terminal right in the dock for them and then ask yourself "Is it secure?"

If your answer is that would be if you just got rid of Terminal.app. Slap yourself really hard and repeat the question :)

Once you are past that then you can actually address the real root cause of your security problems.

-Eric
 
Yeah, i can see your meaning - i really appreciate people taking the time to explain things like this. Heh, the only computer network that is truly secure is one where all the nodes are turned off and unplugged! - lmao!
 
scruffy said:
grep - you forgot to encase the computers in concrete and drop them in a river

I opened this thread some time back. Must I conclude that dropping my iMac into a river (incased in concrete) is the only way I can secure a drop box? ;)
 
Back
Top