Security concerns with Solaris 2.X

Security concerns with Solaris 2.X

Post by Rob Cas » Sat, 05 Aug 1995 04:00:00

I have some concerns about Solaris security.  On my system, freshly
cloned, /dev/ip, /dev/tcp, /dev/arp, etc. are all world writable!
(Actually they are links to ../devices/pseudo/.... ; those are the
files with the bad? permissions.)  So, is this really bad or do the
device drivers have some built-in intelligence about permissions.
For example, joe user shouldn't be able to open /dev/le and read all
the packets coming into the machine (which would include unencrypted
passwords), but joe user should be able to at least read protocol
statistics from /dev/le.

Could you please at least mail me a response?  This newsgroup has
so much volume that it's hard to keep up.  Plus I going on vacation
so I won't be around to read net news.

Thanks in advance,

 Rob Cash, Information Systems Specialist        Voice: 919/481-7025
 Operating Systems Integration                   FAX:   919/481-8674

 Nortel, Inc         100 Perimeter Park            



1. Security question concerning port security and SSH.

I'm developing a program for people around my office to use, it
communicates over TCP and someone brought up security issues.  Right now
we have two different oppinions on how to settle this and I was hoping
someone here could clear things up a little.  The program is two parts: a
perl script on a remote machine that accepts one argument, then opens up a
TCP connection to my local computer over some port of my choosing and
conveys this one argument to an application I have listening on my
computer to that port.  The application then processes this argument and
sends it onto another application to use.  The concern now is that someone
could port-scan the local computer, and flood my port with information
which would in turn would make my application flood the other application
its communicating with, making it useless.
My coworkers' suggestion is to instead have the script on the remote
machine open a SSH session to my local computer and just run another PERL
script that communicates to the final application, then close and re-open
the session every time.  My idea is to use my current script but add a
variable that contains a 10 digit number, then pass this number along with
the original argument.  The listening application on my local machine also
knows this special number and will only listen to requests that pass this
number.  Nobody else can find out this number because the script on the
remote machine will have 700 permissions, and I'll set the number after
the permissions are set to 700.  Granted someone could hack into the
remote machine as me, but that would be a whole other world of issues.
I want to do it my way because not only will it be virtually no extra
development time (like 5 mins to add the extra argument), where the other
way would require rewriting the sending script and creating a listening
script.  But also because as it is now just sending data over this TCP
port it takes all of 2 seconds from start to finish, if I had to open a
SSH session every time I'm sure it would increase the time.
I see no difference between having my port (say 5938) only listen to
certain messages, and the SSH host (21 or whatever) which also will only
listen to a message that has been security checked.  In fact, the only way
my solution would fail (besides someone finding out the number) is if they
just attacked the port with brute force, but the SSH port would fail in
the same situation.  I feel that the other solution is spawned from a
general trust in the security of SSH, but I don't need this data
encrypted, which is the big deal of SSH, so I would have to put up with
the overhead of SSH but not really use it.

Any opinions would be appreciated.

2. How do you program without sessions in Apache

3. Concerns about upgrading from Solaris 2.6 to Solaris 7 or 8

4. Config prob? .html but no .htm ???

5. Linux security concerns I should heed?

6. getrusage !!(was How big a hog am i???)

7. Concern over Windows and Security

8. voodoo3 fb device

9. security concerns with access to cgi-bin for www?

10. W3-mSQL and data with an apostrophe and security concerns

11. Security concerns

12. ISDN security concerns

13. Security Concern