restrict rexec by user 1

[ksas025]

Is there any way to restrict rexec access by user instead of host? I have used TCP wrappers to tighten down network access to the rexec daemon but what I really want is to restrict rexec by user.

 

[spamly]

Ever thought about eliminating rexec and using ssh access with rsa key authentication? You would then be able to lock the connections down to a user and/or a host.

-Tim

 

[khalidaaa]

spamly is right and here is some good links for ssh:

http://www.tek-tips.com/viewthread.cfm?qid=1207338&page=1

And this is another link for using the dsh:

http://www.tek-tips.com/viewthread.cfm?qid=1353921

Regards,
Khalid

 

[ksas025]

Thanks for the responses but my environment requires the use of rexec for the time being. The vendor who develops our system has not incorporated SSH into its code. Therefore discovering a way to restrict rexec by user would be the next best step.

I am aware of security best practice but they are simply not applicable here.

Thanks for any additional responses.

 

[ksas025]

As you have probably guessed, I am attempting to tighten rexec access from remote hosts to my User servers. One of my policies is to deny remote logons of the root user via /etc/security/user via the rlogin = false directive. This works great for protocols suchas telnet and rlogin/xlogin but does not work for rexec or rsh. Why is that? Is there anything I can do to restrict root via rexec and still allow my end users to use it?

Thanks again.

 

[RodKnowlton]

[tt]man rhosts[/tt]

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

A Simple Code for Posting on the Web

 

[ksas025]

I am not sure if rhosts is working for me. Even after I enter -<hostname> in the ~/.rhosts it still allows me to use Exceed to rexec from that windows client. It does restrict rsh however. Is this the expected behavior?

I just cant seem to restrict rexec from my Windows exceed clients.

 

[RodKnowlton]

Sorry, I thought rexec was an "r-command" like rsh and rcp, but it's a different beast, and doesn't care about rhosts or hosts.equiv.

Hopefully someone else will have an idea how to secure it, because the only method I've found is to disable it altogether.

IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

A Simple Code for Posting on the Web

 

[mrn]

You could (But I wouldn't) put a wrapper round the command, along the lines

if ( uname = "username" -o uname = "another_user" )
then
run command
else
echo "not allowed"
fi

rename / alias rexec call from script

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[ksas025]

Do you mean a wrapper around rexecd? That would mean (i think) that I would alter inetd.conf to look at another file then pass control to rexecd if authorized? Is that correct?

How would you pass control to rexecd? Is rexecd open source? Maybe I can look at the code to see what it expects.

 

[ksas025]

For whoever is interested I ended up doing what mrn suggested. I wrote a Perl script that accepts the rexec compliant string passed to socket TCP/512. The Perl script then scrutinizes the string received by the client for user and execute information. If the calling user is not in a file held in the /etc directory the perl script kills the connection. If the user exists then it passes the unmodified login string to the real rexecd which I configured to listen on a different port. Since the remote rexec request has DISPLAY information included, the real rexecd does not care where the request comes from but simply check the password and executes the command if allowed.

After about 2 weeks in a development environment it seems to work well. I believe this to be an acceptable solution for environments that *must* have rexec service available.

Thanks all for their help.

 

[RodKnowlton]

You may have already done this, but you should tighten down your tcpwrapper on rexecd to only accept connections from localhost. Otherwise all an unauthorized user needs to do to bypass your program is find out what the new rexecd port is.

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

A Simple Code for Posting on the Web

 

[abubasim]

To disallow inbound rexec access to a user:

# chuser ttys=ALL,!REXEC username

This is assuming that the ttys parameter for the user is the default "ALL". Check this with "lsuser -a ttys username".

This mechanism can also be used to block inbound rsh access:

# chuser ttys=ALL,!RSH username

or both:

# chuser ttys=ALL,!REXEC,!RSH username

 

[mrn]

Not tidy but what about a wrapper?

http://www.gratisoft.us/pipermail/sudo-users/2003-February/001410.html

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[mrn]

Don't know why I replied to this again. One of those days......

Mike

"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."

 

[ksas025]

Abubasim, I thank you. Your solution is the simplest and best for what I want to do. Using the /etc/security/user file I can deny rexec by user by simply listing the !REXEC in the tty= directive of the user's stanza. Now that is tidy!

Thanks to all for your replies!

Alex