Click on our Sponsors to help Support SunWorld

January letters to the editor

January 1997

Mail this
article to
a friend

You state in your recent SunWorld article on Java and ActiveX security models:

"Microsoft has also adopted this model and is implementing, in the Internet Explorer 3.01 and 4.0 releases, the same type of granularity in security control. Code signature revocation is available today in Internet Explorer 3.01. A good example of the value of this feature is the infamous Exploder control attack on ActiveX. In that situation, the developer of the control applied and received a personal digital signature from Verisign. The control was then posted on the Internet and downloaded by users to demonstrate that ActiveX controls could be signed and still cause damage.
Shortly after the control was posted, Verisign notified the author that he had violated the agreement with Verisign by using the digital signature to post malicious code. The code was removed from the Internet and the author's digital certificate with Verisign was revoked. Now Internet Explorer can be commanded to check the status of certificates and remove those that have been revoked, disabling those ActiveX controls that are signed by that revoked author."

Such a response is all well and good provided the trust ensurence mechanism (Verisign, here) knows the identity of the rogue developer using the mechanism in this torjan horse manner. If the author of the Exploder ActiveX control had never made his identity voluntarily known to us all, what feature of this trust model for software deployment would have figured out his identity and lead to the same results, and how long (or how many episodes of destructive behavior with self-cleaning of the audit trail) would there be before some audit trail could be established to determine the identity of the attacker?

The scenario is identical to the torjan horse uploads to bulletin boards in years past. The most efficient way to defuse such "digital bombs" is to ask the trust mechanism (here Verisign) to first test-run every ActiveX control on a stand-alone or sacrifical machine in an environment sufficently representative of the broadest base of potential downloaders for the control before the control is permitted to be released with a signiture. This is akin to the BBS operator testing/scanning all posts to the BBS from outside sources.

Note that efficiency here refers to time/resources spent to isolate a rogue ActiveX control before it does damage. From the point of view of business distribution costs, this may be rather expensive since every ActiveX control from every developer would be bottle-necked through this trust mechanism checkpoint.

John Malley
Virtual Vision, Inc.

Setting up anonymous FTP for Solaris

To Peter Galvin: I just set up anonymous FTP for Solaris (previously I had configured it for SunOS, which is of course totally different), and I have a few extra tips in addition to what is mentioned in the ftpd man page. You should add them to your security FAQ.

I'm using Solaris 2.5.1, but this should apply equally to Solaris 2.5.

1) In order to show the correct user and group ID's in "ls -l", you need to copy the /usr/lib/libmp.so.1 library in addition to all of the other libraries in ~ftp/usr/lib.

2) If you're using NIS+, and want to search NIS+ for user and group ID's (again, for "ls -l"), you need to copy NIS_COLD_START and NIS_SHARED_DIRCACHE from /var/nis to ~ftp/var/nis. You also have to copy /etc/nsswitch.conf to ~ftp/etc, of course.

3) You need the correct timezone info in ~ftp/usr/share/lib/zoneinfo, but you don't need ALL the timezones. If you want to save almost 400k, you can copy just the timezone you need (for example "US/Pacific"). Do an "ls -l" from within FTP and from a shell prompt, and make sure the two times agree.

Here's another tip if you are having any problems with anonymous FTP (for example, if you want to set up wu-ftpd). Follow these steps and you can run a system call trace on ls in the same chroot'ed environment that ftpd uses.

# mount -F lofs /proc ~ftp/proc   # loopback mount /proc (truss needs it)

# cp /usr/bin/truss ~ftp/usr/bin  # copy the truss command itself

# chroot ~ftp /bin/truss /bin/ls -l /pub   # or any other command

# rm ~ftp/usr/bin/truss

# umount ~ftp/proc

You will need to substitute ~ftp for the absolute pathname of the FTP home directory. Enjoy! Jake Hamby

The Solaris Security FAQ

To Peter Galvin: Thank you very much for all of the tips and advise you have made available through SunWorld! I was reading the Security FAQ and have a question on one topic you addressed. The question was "2.9 Why do Solaris machines act as routers?" You mention that routing can be turned off on Solaris 2.5 by touching the file /etc/notrouter. Currently I disable routing by setting a default router in /etc/defaultrouter. /etc/defaultrouter has the IP address of the network router. If I set /etc/notrouter and don't have /etc/defaultrouter, will Solaris be able to access other networks? Will Solaris auto-discover the router? Joe Ward,
Square D Company Peter Galvin responds: Joe: These two mechanisms (Why do Solaris machines act as routers and turning off routing by touching the file /etc/notrouter) are separate. If your Solaris machine has only one network interface, it won't route. If it has two or more, it will route packets between the networks. This is sometimes indesirable, especially when the Sun connects two networks in different security domains. In that case you'll want to prevent the Sun from acting as a router and effectively connecting the two networks together. Concerning the question about disabling routing by setting a default router in /etc/defaultrouter, this doesn't disable the Sun from acting as a router. Rather, it tells the Sun where to send it's packets for routing, that is, it tells the Sun to how the Sun can get to networks it doesn't know about. It has nothing to do with whether the Sun will take packets from one of its networks and send them to another of its networks. Finally, concerning your question about setting /etc/notrouter and not having /etc/defaultrouter, if you look at the startup files (/etc/init.d/inetinit I believe), you'll see that route discovery is turned on by default, so yes, you can disable the Sun acting as a router while still having it automatically discover routes and use them to send packets from itself to other networks. It's not *passing* packets for other machines though.

Help needed with mail

Editor: Please, help me. We have a workstation running Solaris 2.5 and it is refusing to receive mail. I mean, I can send mail from the machine, but I can't receive mail on it. Here you have the return message. Looks like "local configuration error" and "mail loops back to myself." Is this a problem of sendmail.cf or could be something wrong with the smart relay host? I tested the "telnet indis 25" and the mail daemon is alive. I tested "mailx -v adrianc@indis" too, and the dialogue between the machines seems to be appropriate. What else could I do? Thank you very much. Adrian Corbuleanu Readers:
Do you have any suggestions for Adrian, who lives in Romania? If so, please address them to me and I will print them next month.
--Editor

Reader needs help with PPP on Solaris

Editor: Reading through your introduction at the end of my SunWorld e-mail led me to believe you were both knowledgeable and approachable. So I come to you on bended key, asking for your assistance with Sun PPP. Just to give you a brief background, I have strong experience with Windows (All flavors), (and in fact, am currently dialed in using a PC with PPP), but have only been working with Unix, specifically Solaris, for about six months. I have taken SA-135 and SA-285, but have been unable to setup PPP, and no one seems to know how. Not even at the Sun training facility I attended in Chicago. The corporate office Unix gurus(in the company I work for), claim they haven't a clue how to setup PPP, and that they use ISDN from home. We have a platinum Sun Support account, which should enable us to get answers to questions like this, but I have tried three times to get assistance. The first two people I spoke with didn't have the knowledge to help me. The last gentleman I spoke with, sounded a little older, and more knowledgeable, and e-mailed a forty page document that was not terribly helpful. My complaint is that the document (like many in the Unix world), was written in a style that leads you to believe it was composed by a half awake engineer under a severe deadline, who never actually tried to use it to see if it communicated. Ok, that was a slam, but I am frustrated. I have a Sun at home, and want to be able to dial in with it to administer the network, but have been unable to make sense of the information. I am also frustrated in general with the Unix educational community. Surely a class of people this intelligent, who can learn the wonderfully complex Unix OS, could spawn someone who can communicate. Do you or someone you know, have the ability to setup PPP on a Sun, and could you please help me? Thank you for your time,
Scot Corrie
Riverside Publishing, Div. of Houghton Mifflin Readers:
Do you have experience with PPP on Sun? If you can shed some light on Scot's delimma, please send your answers to me (stephen.lawton@sunworld.com), and I will publish it next month.

Kudos for SunWorld

Editor: Great job on the bar charts regarding what's hot. Carlos Sanchez Carlos: Thanks. Glad you like them. We're always interested in knowing what works and what doesn't. It's interactive feedback like this that makes it possible to keep improving each month's issues. Readers, we'd like to hear back from you too. If there's something we do very well or poorly, let me know. Send your comments to: stephen.lawton@sunworld.com. Make sure you include your name, and preferrably, your company affiliation too. We'll run them -- the good and the bad.
--Editor

If you have problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-01-1997/swol-01-letters.html
Last updated: 1 January 1997

<A HREF="http://ad.doubleclick.net/jump/idg.sw.com/features;sz=468x60;tile=1"><IMG SRC="http://ad.doubleclick.net/ad/idg.sw.com/features;sz=468x60;tile=1" width=468 height=60></A>
Click on our Sponsors to help Support SunWorld

What did you think of this article?

-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

Comments:
Name:

Email:

Company Name:

If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-01-1997/swol-01-letters.html
Last modified: