I have tested this on the newest version (3.0.15) of the ICA Client for Linux and found some differences. The /usr/lib/ICAClient dir is now mode 755 which is good, but it keeps each users appsrv.ini in ~/.ICAClient now, which is mode 755 too, so still anyone can read the file. Another workaround would be to not enter a user/domain/password in the connection configuration screen, and enter it manually in the standard NT login screen each time the connection is made. David Terrell wrote: > [ presumably this holds true for the other unix clients as well, but > all I have is linux to test on ] > > The Citrix Winframe linux client (used for accessing Winframe and > Windows NT Server Terminal Edition) has a simple configuration section. > Perhaps too simple.... All configuration information is stored in a > directory /usr/lib/ICAClient/config which is mode 777. This in and > of itself is bad news, since any user on the system can overwrite > configuration data. > > The situation is actually much worse than that. > > When you start up the actual session manager (wfcmgr) you get a listbox > of configured sessions. The data for this listbox is stored in the mode > 777 file /usr/lib/ICAClient/config/appsrv.ini. So there's a single > config file shared between all users. A sample session profile follows: > > [WFClient] > Version=1 > > [ApplicationServers] > broken= > > [broken] > WinStationDriver=ICA 3.0 > TransportDriver=TCP/IP > DesiredColor=2 > Password=0006f6c601930785 > Domain=NTDOM > Username=user > Address=hostname > > Yep. Passwords are stored in some kind of hash. What that hash is doesn't > really matter since you can just bring up wfcmgr and log in as that user. > > Terrible. > > I tried mailing both supportat_private and securityat_private but > neither of these addresses exist. > > Workaround? wfcmgr supports the -icaroot parameter, but you basically > need to copy all the files in for it to work. So duplicate the tree in > your home directory, fix permissions, and do wfcmgr -icaroot $HOME/.ica. > > Alternatively, don't use it. > > Distressing that the company that was "bringing multiuser concurrent logons > to Windows NT" makes such a little effort at understanding multiuser > security.... [further editorialization left to the reader] > > -- > David Terrell > dbtat_private, dbtat_private I may or may not be speaking for Nebcorp, > http://wwn.nebcorp.com/~dbt/ but Nebcorp has spoken for you.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:47:36 PDT