You may wish to do what we have done with our application running on all platforms, not just Linux/390. We direct logs files out through a secure port to one or more "log servers". The level of detail of this action is set by the system administrator and the log files for the application are reviewed at one or more workstations located in one or more areas.
For secured access to the system by the administrator(s), use SSH/Telnet. For log files, see above. This can be done with syslog as well. Thanks, Steve Guthrie -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Warren Sent: Monday, March 24, 2003 12:32 PM To: [EMAIL PROTECTED] Subject: Re: Read-Only Telnet > So the first question is: what do they need shell access for? do they > need full shell access? > > * What do they need to run? Is it a something from certain set of > commands? If so: take a look at rbash, pdmenu, and similar. The prime example that the developers keep bringing up is along these lines: User A calls in a problem which working with the app via their browser.The developer wants to ssh into the host and issue a tail -f logfile while the user is doing their thing to better understand the sequence of events causing the problem. With the current FTP method, it becomes difficult to completely correlate User Action A with Log message B, especially if their are other folks working just fine at the time. rbash was one of the ones that came up in my searches after your earlier post, but I haven't really had time just yet to delve deeper into just how restricted, "restricted" is. (Specifically preventing the modifications of files you might otherwise gain access to via world permissions). > Generally a shell user is not supposed to be able to harm the system in > any way I frankly feel pretty good about the permissions elsewhere on the box, (Famous last words) however given that I have such little control over the permissions within this applications directories, I was hoping there was a "safer" way. Something that would override any "world" permissions. In my ideal pipe dream, not only would I be able to see "You can look but you can't touch", but I would even be able to deny access to "You shouldn't be here ever ever ever" types of files. (Although the vendor appears to have done this much right. I should be able to do that with group permissions right now, but it would be a nice thing to be SURE). > Mounting the system read-only may work. But remember that some actual > work has to be done on this system. That is: those developers need to > actually change config files. We have a change management process in place, so if they go in and determine the problem requires a change, they would need to go to the development system, make the changes and promote them as needed, so in this case, the "Read-Only" image might be a good way of doing what I need to do. On a side note, the security admin suggested that a different way to tackle this might be through key-stroke auditing, we could allow the developers in doing the best we could with permissions as they are and send a report of what EXACTLY they did somewhere that they couldn't get to. That way IF someone did something bad we could at least figure out who/what/where/and when, (why would be a whole different can of worms).. Any suggestions down that road would be appreciated too. Thanks! ----------------------------------- Jeremy Warren Sr. Systems Programmer KB Toy Stores mailto:[EMAIL PROTECTED]@kbtoys.com |---------+----------------------------> | | Tzafrir Cohen | | | <[EMAIL PROTECTED]| | | .ac.il> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | | | | | | | | 03/24/2003 12:37 | | | PM | | | Please respond to| | | Linux on 390 Port| | | | |---------+----------------------------> >--------------------------------------------------------------------------- --------------------------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: [LINUX-390] Read-Only Telnet | >--------------------------------------------------------------------------- --------------------------------------------------| On Mon, Mar 24, 2003 at 11:19:42AM -0500, Jeremy Warren wrote: > Sorry for the lack of detail... > > Basically, > > It's a 3rd party java based application, numerous configuration files, etc, > which are dynamically updated via the application itself. Lots of log > files, etc. The users access it via a web page front end, but our > developers are asking to get "beneath the covers" while it's running. > > Right now I am using a restricted ftpd where then can only do "gets" from > various directories. That way they can pull the files back that they need > to look at for debugging, monitoring, etc. The developers are complaining > that what they really need is "telnet/ssh" access so that they can get in > and look at the filesystem as a whole. I realize that they "should" be > able to do this all via FTP, but I have been told to come up with a > solution to make this work for them. ftp is bad to begin with, as it has trivial plaint-text authentication, like telnet and pop3. It is no use limiting their access to the system to restricted "guest accunts": whoever has access to those accounts (possibly by sniffing) is able to write the configuration files of this complex java app. The developers want shell access. Shell access is considered problematic because a user with a shell account is in a better position to harm the system. However a system generally needs user in order to get something done (sysadmins are also known to be the causes of some incidents to systems from time to time ;-) ). So the first question is: what do they need shell access for? do they need full shell access? * What do they need to run? Is it a something from certain set of commands? If so: take a look at rbash, pdmenu, and similar. > > So I guess a better way to word it would be that I am looking for a way to > grant them read-only access to the filesystems on the host. But Linux > Owner/Group/World Permissions won't work since I can't really muck with > them since they are set by the vendor. They have certain areas which are > validly world writeable, but where an accidental key stroke could wreak > havoc on the app, so I need to guarantee read only to those areas. ( I > sure do miss RACF at times ) A standard unix shell account gives "read-only" access to the system, except to the home directory, /tmp and a number of other places. Generally a shell user is not supposed to be able to harm the system in any way (though defending the system against denial-of-service from local shell users: fork bombs and friends, takes some extra settings). Any such method is a security hole that should yield a security-fix of a locally-exploitable security hole. Note that I wrote "is not supposed to" and not "is not". You are keeping your systems up-to-date, right? > > I like the idea of another image which mounts all the filesystems RO, but I > need to investigate it further and try some experiments. I have also found > a couple of interesting discussions by searching on kiosk and restricted > shell which Tzafrir Cohen recommended, but I still need to do some digging. Mounting the system read-only may work. But remember that some actual work has to be done on this system. That is: those developers need to actually change config files. -- Tzafrir Cohen +---------------------------+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---------------------------+
