4

Background: We have a lab of Macintosh computers, all running 10.10.3 currently, that are for classroom instruction. Students typically use their own login/password via Active Directory to log in to these machines, however guest(anonymous) access is also available. Traditionally we have never previously allowed students to open/use Terminal.app as the room was used primarily for art, but recently the machines are being used for science and instructors have requested CLI access. Students are not admins and would not be able to use sudo.

Is it safe to remove the restriction preventing students from opening Terminal.app and allow students full access to the bash shell? Are we being over cautious? If not, what types of risks would we be exposed to/need to address prior to allowing such access?

  • I hope 'Ask Different' is an appropriate place for this question, I also considered placing it under 'Super User' or 'Information Security'. – user83417 Jan 13 '16 at 0:20
  • 1
    If your science instructors can tell you exactly what it is that their students will be doing that requires using Terminal & as long as that usage requirement can be met without giving the students sudo access then you might have sufficient information for an informed decision one way or the other. – KarlC Jan 13 '16 at 1:23
  • As stated, students will not have the ability or the need to use sudo. Some of my colleagues are concerned that allowing the use of Terminal is a security hole, but have provided, imo, little evidence. I'm hoping someone can provide a solid argument for or against. – user83417 Jan 13 '16 at 15:57
6

It's important to realize that students already have other avenues of access to the bash (and other) shells. Students can download alternate terminal programs—such as iTerm—to their home directories to gain shell/CLI access. Additionally, shell scripts can be run via Automator.app.

So, especially for enterprising students, blocking the default Terminal.app hasn't bought you much from a security standpoint.

Really, whether CLI access is appropriate comes down to the intact permissions across the filesystem combined with appropriate user account settings. If the students are running as standard or managed (non-admin) accounts and filesystem permissions are intact, then that's what limits student access. Non-admin accounts shouldn't be able to run root-level tools and modify root-level configuration files.

  • Good to know, thank you. Obiviously I didn't include our entire policy setup in my background info, currently we don't allow executable files to run outside of /Applications, and only admins can write to /Applications. – user83417 Jan 14 '16 at 15:52
  • Sure, it's hard to list an entire security policy in a short posting. I wasn't aware that there's a way to disallow the launching of apps in one's own home directory. It's off-topic, but it'd be interesting to know how you do it. Even so, Automator.app is in /Applications and can be used to do shell-like things. – jefe2000 Jan 14 '16 at 16:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .