Paul Green and I were discussing a new command he’s working on called check_module_security. The subject of unnecessary commands available at the login prompt came up. Jon Schmidt of Transaction Design recommends in an article about Locking the Barn Door.
Internal Commands:
display_current_module (prelogin)
list_modules (prelogin) display_date_time (prelogin)
list_systems (prelogin)
display_line (prelogin)
login (prelogin)
If there are other commands shown, remove them.
I got to thinking about commands like list_modules and list_systems; even if you had taken the trouble to secure your own module or system, these commands might give a hacker a hint about other modules/systems that might not be as secure and could be exploited with login -module. So we wondered about how to prevent their use at prelogin time. Here’s one way that I found:
Create a uniquely-named file for use as an access list name. In this case, I chose prelogin_no_access to be attached to any command that I want to forbid some users from accessing. The contents of the file have no use – it’s the access control lists that are attached to it that matter. The file goes in a special place: (master_disk)>system>acl directory. The user that we want to restrict is PreLogin.System, which is the user that executes the login prompt. Don’t forget to allow access for other users (after login). You must be a privileged user and member of the SysAdmin group at most sites to perform these operations.
change_current_dir (master_disk)>system>acl
create_file prelogin_no_access
give_access null prelogin_no_access -user PreLogin.System
give_access write prelogin_no_access -user *.*
Ensure that the commands you want to restrict are configured in internal_commands.tin to use that access list…
%phx_vos#m14_mas>system.14.7>configuration>internal_commands.tin 07-10-02 12:14
/ =name display_current_module
=access_list_name prelogin_no_access
=audit 0
/ =name list_modules
=access_list_name prelogin_no_access
=audit 0
If you had to make a change, then you need to apply the changes.
create_table internal_commands.ti
broadcast_file internal_commands.table (master_disk)>system
configure_commands
Now, you can try to use a forbidden command at login
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:19
help
Internal Commands:
change_password (prelogin) help (prelogin)
display_current_module (prelogin) list_modules (prelogin)
display_date_time (prelogin) list_systems (prelogin)
display_line (prelogin) login (prelogin)
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:23
list_modules
command_processor: Not enough access to perform operation. list_modules.
I didn’t restrict ALL the internal commands; so the ones that are not affected can still be used.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:29
list_systems
phx_osn . . . . . . online (local)
phx_test . . . . . . online (local)
phx_vos . . . . . . online (current system)
So remember to restrict those that you think are important.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:39
display_current_module
command_processor: Not enough access to perform operation.
display_current_module.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:53
There’s a bonus: if you have security logging enabled, a security log entry is made to tell you that somebody tried to use one of the commands.
1: 07-10-02 12:16:20 mst PreLogin.System %phx_vos#tli_log.m15_65
Target: list_modules
Text: Not enough access to perform operation. Validating object access.
Did we get everything? Not by a long shot. Here’s a small list of the shortcomings of this quick tutorial:
– The login banner still gives the module name, even though list_modules and display_current_module commands are disabled.
– The login banner still gives the clue that this is a VOS system when it displays the release name.
– The list_systems command is still operational (deliberate for this example, but it should be prohibited as well).
Bonus points to those who spot what else could be done. Hint: command functions still work.
-Dan Danz, VOS Services Technical Consultant
Paul Green and I were discussing a new command he’s working on called check_module_security. The subject of unnecessary commands available at the login prompt came up. Jon Schmidt of Transaction Design recommends in an article about Locking the Barn Door.
Internal Commands:
display_current_module (prelogin)
list_modules (prelogin) display_date_time (prelogin)
list_systems (prelogin)
display_line (prelogin)
login (prelogin)
If there are other commands shown, remove them.
I got to thinking about commands like list_modules and list_systems; even if you had taken the trouble to secure your own module or system, these commands might give a hacker a hint about other modules/systems that might not be as secure and could be exploited with login -module. So we wondered about how to prevent their use at prelogin time. Here’s one way that I found:
Create a uniquely-named file for use as an access list name. In this case, I chose prelogin_no_access to be attached to any command that I want to forbid some users from accessing. The contents of the file have no use – it’s the access control lists that are attached to it that matter. The file goes in a special place: (master_disk)>system>acl directory. The user that we want to restrict is PreLogin.System, which is the user that executes the login prompt. Don’t forget to allow access for other users (after login). You must be a privileged user and member of the SysAdmin group at most sites to perform these operations.
change_current_dir (master_disk)>system>acl
create_file prelogin_no_access
give_access null prelogin_no_access -user PreLogin.System
give_access write prelogin_no_access -user *.*
Ensure that the commands you want to restrict are configured in internal_commands.tin to use that access list…
%phx_vos#m14_mas>system.14.7>configuration>internal_commands.tin 07-10-02 12:14
/ =name display_current_module
=access_list_name prelogin_no_access
=audit 0
/ =name list_modules
=access_list_name prelogin_no_access
=audit 0
If you had to make a change, then you need to apply the changes.
create_table internal_commands.ti
broadcast_file internal_commands.table (master_disk)>system
configure_commands
Now, you can try to use a forbidden command at login
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:19
help
Internal Commands:
change_password (prelogin) help (prelogin)
display_current_module (prelogin) list_modules (prelogin)
display_date_time (prelogin) list_systems (prelogin)
display_line (prelogin) login (prelogin)
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:23
list_modules
command_processor: Not enough access to perform operation. list_modules.
I didn’t restrict ALL the internal commands; so the ones that are not affected can still be used.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:29
list_systems
phx_osn . . . . . . online (local)
phx_test . . . . . . online (local)
phx_vos . . . . . . online (current system)
So remember to restrict those that you think are important.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:39
display_current_module
command_processor: Not enough access to perform operation.
display_current_module.
VOS Release 15.3.0ai, Module %phx_vos#m15
Please login 12:13:53
There’s a bonus: if you have security logging enabled, a security log entry is made to tell you that somebody tried to use one of the commands.
1: 07-10-02 12:16:20 mst PreLogin.System %phx_vos#tli_log.m15_65
Target: list_modules
Text: Not enough access to perform operation. Validating object access.
Did we get everything? Not by a long shot. Here’s a small list of the shortcomings of this quick tutorial:
– The login banner still gives the module name, even though list_modules and display_current_module commands are disabled.
– The login banner still gives the clue that this is a VOS system when it displays the release name.
– The list_systems command is still operational (deliberate for this example, but it should be prohibited as well).
Bonus points to those who spot what else could be done. Hint: command functions still work.
Company