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.