File Permissions on /dev

[joe_91]

Hi There:

The following files' permission are shown vulnerable by the security audit software as it says the following world writable file/directory referenced in startup script.

startup script. file
/sbin/init.d/hpbase100 /dev/ether0
/sbin/init.d/net.init /dev/ip
/sbin/init.d/net.init /dev/tcp
/sbin/init.d/nfs.core /dev/tlclts
/sbin/init.d/nfs.core /dev/tlcotsod
/sbin/init.d/nfs.core /dev/tlcots

To get past this i think we need to change the permissions to 644. But i am not too sure what these files are for and what would be the impact of making them 644. Can someone help here?

Thanks in advance,

Joe.

[Martin Johnson]

I would be very careful about changing permissions of files in /dev. Changing /dev/ether0, /dev/ip or /dev/tcp will negatively impact your network.

Remember that /dev contains device files. Changing permissions here will affect users attempting you use a device.

HTH
Marthy

[Rich Wright]

Joe,
These should all be device I/O files.
Verify with "ll -d /dev/*".
The first character should be "c".

If these are regular files and not device files, then you need to create new ones with "mknod" command.

Device files need to be world writable for I/O to work.

Be sure that /dev has dr-xr-xr-x permissions.

[Christopher McCray_1]

Hello,

I am not sure of the nature of your security software, but we undergo the sam type of thing.

for your /sbin/init.d files, I would change them to 755, 555, or 550. I mean, they are scripts, afterall and wouldn't/shouldn't be edited by anyone but root anyway and this will get rid of your "world writeable" problem. As for your /dev files, I looked at mine and they are all 777 for those particular ones and our software didn't complain. I would test this out on another test system to see what impact, if any, there is. Or your other option is to stand your ground because those are important device files for your networking protocols and could hose things up, just as Martin suggested.

Hope this helps

Chris

[joe_91]

True. But it looks like we have get thru this audit also. I think the issue is the startup script references a world writable file/directory not with /dev files.

Thanks
Joe.

[joe_91]

Hi Chris:

May be we could try 550 on the /sbin/init.d files as they are already having a permission of 555. But i am not sure of the impact on the 1000 odd users.

Thanks
Joe.

[Martin Johnson]

The /sbin/init.d scripts are used by root during startup and shutdown. Changing the permissions on those scripts should not affect anything unless you allow users to recycle software components (which is unlikely, since most require root authority).

Removing world access to /sbin/init.d scripts should satisfy your auditing requirements. If they insist on doing /dev tell them that removing world access will make the system unuseable for the users, which is true.

HTH
Marty

[Bill Hassell]

It's not clear from your question if the permissions of the files in /sbin/init.d/ are in question, or the devicefiles in /dev are of concern. To be safe, *ALL* the files in /sbin/init.d should be a minimum of 755, the default is 555. Since these files must owned by bin, there is no issue of ordinary user modifying them. And of course, the directories /sbin and /sbin/init.d must be 555, owned by bin.

As far as the device files, these must all be 666. Change these permissions and your networking will break. Possibly, your security scanner is not designed specifically for HP-UX and is reporting these permissions as incorrect.

[joe_91]

Okay, this is the issue....
The following files have 555 permission
/sbin/init.d/hpbase100
/sbin/init.d/net.init
/sbin/init.d/nfs.core
that is not a issue. but the issue is the following files in /dev
/dev/ether0,/dev/ip,/dev/tcp/dev/tlclts,/dev/tlcotsod,/dev/tlcots are world writable and they are being referenced in the /sbin/init.d files(mentioned above). The security scanner somehow does not like that.

Thanks
joe

[S.K. Chan]

It is very true that devices files that you mentioned in /dev must be 666. I have checked all of my systems and they are 666. Here we are using the Medusa tool to check permissions of files and it never raise a red flag for /dev/ip,/dev/tcp,/dev/ether0 and /dev/tlc*. The tool knows these device files need to be 666. It will complain though if it finds an device files NOT in /dev that has that permission. Some security tool comes with a filter giving flexibility to the sysadmin to exclude certain files from being checked. If your tool has this option you may make use of it since it's not smart enough to determine the validity of the permission for thise files.