Routing

Expand all | Collapse all

User Access Block For Some Commands

Jump to Best Answer
  • 1.  User Access Block For Some Commands

    Posted 11-10-2012 23:13

    Hi There,


    We have requirement to deny below command to users. We have been trying multiple combination also using with regexp but so far we have not found any luck.
    Can you please share you thought for a way out on this requirement?
    or is this possible to deny such command ?

    "delete interfaces"
    "delete protocols"

    below is currnet login configuration we have :

    apply-groups deny_show_bgp_group;
    class L1-Front {
        idle-timeout 10;
        permissions [ network secret security trace view view-configuration ];
    }
    class L1-Plan {
        idle-timeout 10;
        permissions [ network secret security trace view view-configuration ];
        allow-commands "monitor traffic";
        deny-commands "(clear)|(show bgp group)";
    }

     

    When we use deny-command "(delete interfaces)" in above classes the users belong to these classes still able to delete interfaces. Please check



    BR,



  • 2.  RE: User Access Block For Some Commands

    Posted 11-11-2012 09:21

    Hi there,

     

     Can you also paste what "deny_show_bgp_group" is please? The classes L1-Front and L1-Plan should not even be able to do a configure and/or edit, so they can't do any delete as is now.

     

     Cheers,



  • 3.  RE: User Access Block For Some Commands
    Best Answer

    Posted 11-11-2012 11:03

     

    Hey there,

     

     While waiting for your reply, I'd like to take a guess and asssume you're after something like below:

     

    "A limited user class that can do some things on the router, including configuring interfaces but do not delete all of them."

     

    In this case, I would suggest a different approach than your initial example, as the one below:

     

    class Limited-Class {
        idle-timeout 15;
        permissions [ access clear firewall interface maintenance network pgcp-session-mirroring reset rollback routing secret security snmp storage system trace view view-configuration ];
        allow-commands configure;
        allow-configuration "(interfaces .*)|(^class-of-service .*)|(firewall .*)";
    }
    user erdem {
        uid 5555;
        class Limited-Class;
    }

      Note that instead of giving the user permissions all or interface-control (-control means read-write access to that part of the configuration) I've given only the "interface" permission, which is read-only.

     

     However, the class is explicitly allowed to use the configure command (so that the user can enter configuration mode) along with three regular expressions in allow-configuration statement, allowing them to configure/delete a specific interface, COS or firewall item but NOT entirely alter their configuration.

     

     In other words, the " .*" in the regexp forces the user to specify at least one more level in the following stenzas, which they can alter:

     

    [edit interfaces]

    [edit class-of-service]

    [edit firewall]

     

     

     Although their permissions give only read-write access to them, the explicit allow-configuration will take precedence and overwrite.

     

     Logged in as user 'erdem', see what will happen if I try to configure/delete a specific interface, or all of them below. Note that the auto-complete is NOT going to work with edit interfaces command because user erdem has no permission bit interface-control set, so I have to type the whole command manually.

     

    erdem@vetinari> configure
    Entering configuration mode
    [edit]
    erdem@vetinari# edit in
                         ^
    syntax error, expecting <statement> or <identifier>.
    erdem@vetinari# edit in?  
    No valid completions
    [edit]
    erdem@vetinari# edit interfaces
    
    [edit interfaces]
    erdem@vetinari# delete
    Delete everything under this level? [yes,no] (no) yes

    error: permission denied for interfaces: delete

    edit interfaces]
    erdem@vetinari# set ge-0/0/10 description test

    [edit interfaces]
    erdem@vetinari# commit
    commit complete

    [edit interfaces]
    erdem@vetinari# show ge-0/0/10
    description test;

    [edit interfaces]
    erdem@vetinari# delete ge-0/0/10

    [edit interfaces]
    erdem@vetinari# commit
    commit complete

    [edit interfaces]
    erdem@vetinari# show ge-0/0/10

    [edit interfaces]
    erdem@vetinari#

     

        Needless to say, you can play with allow-configuration and permissions in the class to better suit your need.

     

      Hope this helps,

     

     

     

     

     



  • 4.  RE: User Access Block For Some Commands

    Posted 11-11-2012 16:24

    Hi Erdems,

     

    Thanks for your detailed email, its really helpful.

     

    Basically the customer requirement is exactly that the user have permission all flag but not able to delete/deactivate interfaces or protocol. So, i tried multiple combination but it didn't work. I also used regular expression but it didn't work. User still have permission to use delete/deactivate interfaces or protocol.

     

    Like,

     

    permissions all

    deny-commands "(delete interfaces) | (deactivate interfaces) | (delete protocols) | (deactivate protocols) "

     

    As i read documentation that deny or allow commands always accepted either permissions flag are on.

     

    Please comment. Thanks

     

    Regards,

     

     



  • 5.  RE: User Access Block For Some Commands

    Posted 11-11-2012 18:51

     

    Hey there,

     

     Now I see. You need to use deny-configuration knob for that:

     

    [edit system login]
    erdems@vetinari# show 
    class Limited-2 {
        permissions all;
        deny-configuration "interfaces$|protocols$";
    allow-configuration "interfaces .+|protocols .+" } user erdem { uid 5555; idle-timeout 15; class Limited-2; authentication { encrypted-password "$1$Q4h2.UmA$NDdO4Mrc88Ajr65P04FM41"; ## SECRET-DATA } }

     The above configuration would grant all possible permissions (including start shell, which you may want to avoid too, in case the concern is more focused on security than preventing mistakes) except any set/delete/deactivate command for interfaces, without a suffix.

     

     In other words the users in that class can issue a "delete interfaces xe-0/0/0" but NOT "delete interfaces" and can do a "delete protocols bgp" but NOT "delete protocols", as you can see below.

     

    [edit]
    erdem@vetinari# delete interfaces 
    error: permission denied for interfaces: interfaces
    
    [edit]
    erdem@vetinari# delete protocols 
    error: permission denied for protocols: protocols
    
    erdem@vetinari# delete interfaces ge-0/0/1 
    
    [edit]
    erdem@vetinari# delete protocols mpls 
    
    [edit]
    erdem@vetinari# show | compare | count 
    Count: 25 lines
    
    [edit]
    erdem@vetinari#

     

     

     Once again, I would recommend giving thought on what exactly is targeted with this approach.

     

     If it's a simple precaution against fast-typers, then this should be enough. However, if security is a concern IMHO the restrictions should be higher, as in my first post.

     

     FYI, allow-configuration and deny-configuration knobs are fully supported back again from JUNOS 12.1 onwards.

     

     Hope this helps,



  • 6.  RE: User Access Block For Some Commands

    Posted 11-12-2012 02:02

    Hi Eredems,

     

    Thanks for detailed email. Is it possible to modify below example and to block "delete interfaces interface-name" as well.

     

    Thanks

     



  • 7.  RE: User Access Block For Some Commands

    Posted 11-12-2012 13:50
    Hey there, Let me take a step back and ask you this. Normally, 'permissions all' will give in [edit interfaces] section the following rights (partially, or full) - edit an existing configuration - delete an existing configuration - add a new configuration I'm not sure whether adding delete interfaces


  • 8.  RE: User Access Block For Some Commands

    Posted 11-12-2012 22:09

    Hi Ederms,

     

    Thanks for help throughout the way.

     



  • 9.  RE: User Access Block For Some Commands

    Posted 10-21-2019 12:17
    Great. You are genious.