Operating System - HP-UX
1827293 Members
3844 Online
109717 Solutions
New Discussion

Re: /sbin/init.d/inetd <- scurity hole?

 
SOLVED
Go to solution
Alex Lavrov.
Honored Contributor

/sbin/init.d/inetd <- scurity hole?

Hello,

Today I noticed, that in inetd's startup script, there is "umask 000" command. So, every file that is created with services that use inetd, will be created as "rwxrwxrwx" ...

Is it some kind of security hole or there is some goal that I don't see?


Thanx.
I don't give a damn for a man that can only spell a word one way. (M. Twain)
7 REPLIES 7
harry d brown jr
Honored Contributor

Re: /sbin/init.d/inetd <- scurity hole?

This is how I think it works: If inetd opens a socket to listen on, then umask needs to be 000, so other processes can try to communicate on those sockets.

live free or die
harry d brown jr
Live Free or Die
Alex Lavrov.
Honored Contributor

Re: /sbin/init.d/inetd <- scurity hole?

In that case, sockets should be created by inetd and the permissions must be set inside inetd and not in startup script, so the other files won't have 777 permissions.
I don't give a damn for a man that can only spell a word one way. (M. Twain)
TwoProc
Honored Contributor

Re: /sbin/init.d/inetd <- scurity hole?

Yeah, I agree Alex - it sure looks like a security problem - however, in the past when I've gone in and changed the settings and make them generate at different security levels other than wide-open, the services using them don't work anymore. So, it works as Harry says. I don't like it either, as the sockets tend to be created in public areas (/tmp, /var/tmp ) and, at the very least, are subject to being crashed from most anyone doing an rm-f on them. It would be great to find out that there is a way to secure this - hopefully someone has some more insight on this.
We are the people our parents warned us about --Jimmy Buffett
harry d brown jr
Honored Contributor

Re: /sbin/init.d/inetd <- scurity hole?

Alex,

See this:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1116511776207+28353475&threadId=36043

There are no www.cert.org Security Vulnerabilities listed.

live free or die
harry d brown jr
Live Free or Die
Alex Lavrov.
Honored Contributor

Re: /sbin/init.d/inetd <- scurity hole?

Thanx for the replies!

Heh, it seems that there is no really good answer to this issue ....
I don't give a damn for a man that can only spell a word one way. (M. Twain)
Bill Hassell
Honored Contributor
Solution

Re: /sbin/init.d/inetd <- scurity hole?

inetd normally doesn't start processes that create files (other than logfiles) and these services (daemons) usually set their own permissions explicitly. So inetd is OK with umask 000, or put a better way: inetd must have umask 000 or certain services and daemons may not function correctly. It is important to provide umask for all user logins however. Since it is not provided with standard HP-UX, be sure to add umask 022 (or better) to /etc/profile and /etc/csh.login, on every server.


Bill Hassell, sysadmin
Qi Jian Gang
Occasional Advisor

Re: /sbin/init.d/inetd <- scurity hole?

Some of the application use client server, which skips the .profile etc seting and result in generating file with world write
permission. Better give umask 022 in inetd,
and encourage application to set it's own umask when needed.
pizza