lurk
Mitä?
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.)
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.)
g/re/p
I can haz cigar?
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:
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.
davidbrit2
Licensed Computer Geek
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.
g/re/p
I can haz cigar?
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?)
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?)
davidbrit2
Licensed Computer Geek
g/re/p 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. ;-)
scruffy
Notorious Olive Counter
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')
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')
Darkshadow
wandering shadow
No, that's how URLs represent a space character.
lurk
Mitä?
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
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
