Ldif format

Aaron Spangler as at insight.rr.com
Mon May 24 21:48:25 EDT 2004

Yes, that is correct.

One of the goals was to make a centralized area for roles that can be read
much more easily and be audited much easier.  As such, aliases were removed
since there are already techniques for grouping (users, user groups, user
netgroups, hosts, host netgroups, hostname wildcards, network pattern
matching).  The straight-forward design made it much easier to audit and to
reduce typos, mistakes, and accidental granting of too many privileges.

Since sudo entries eventually expand out and because LDAP theoretically has
no limit to the number of attributes on an object, you can easily have a
very large number of commands assigned to a role, and so it made sense to
spell out the roles explicitly.  These thoughts seemed to be in line with
most environments who's sudoers generally consists of User_Alias,
Host_Alias, and Cmnd_Alias triplets where the aliases are rarely re-used.
For example:

User_Alias: DBAS=dba1, dba2, dba3
Host_Alias: ORACLESVRS= orahost1, orahost2, orahost3, orahost4
Cmnd_Alias: DBCMNDS=/etc/init.d/oracle, /usr/bin/dump, /usr/bin/restore
# the entry

.. and then the aliases are rarely reused except in a few cases.  Most of
the time is spent reading backward and forward through the same file by a
human who hopes to not make a mistake while auditing and granting

Please tell me what you think.  Your thoughts and ideas are welcome

----- Original Message ----- 
From: "Galen Johnson" <Galen.Johnson at sas.com>
To: "Aaron Spangler" <as at insight.rr.com>; <sudo-users at sudo.ws>
Sent: Monday, May 24, 2004 10:34 AM
Subject: RE: Ldif format

> Aaron,
> Am I mistaken that you did not include the Cmnd_Alias in the schema?
> =G=
> -----Original Message-----
> From: Aaron Spangler [mailto:as at insight.rr.com]
> Sent: Sunday, May 23, 2004 12:06 AM
> To: Galen Johnson; sudo-users at sudo.ws
> Subject: Re: Ldif format
> Galen,
> I'm sorry I have been slow.  Here is what yours should look like.  ( I put
> this together by hand rather than use the sudoers2ldif scripts.  There
> be a typo or two)  I suspect the sudoers2ldiff script needs to be
> I have intermixed the LDIF format with the original sudoers format
> > Defaults !root_sudo, ignore_local_sudoers, always_set_home,
> passprompt="Your password: ", \
> > mail_no_perms, mail_no_host, runas_default=adm, mail_no_user, \
> > !set_logname, syslog=local2, mailto="root at domain.com"
> This one translates to the new model perfectly.  The cn=defaults is a
> name used by sudo for the global default options.  Notice the missing
> on the string literals.  Also I am making the assumptions that there is a
> line "sudoers_base ou=sudoers,o=example.com" in /etc/ldap.conf.
> dn: cn=defaults,ou=sudoers,o=example.com
> cn: defaults
> objectClass: top
> objectClass: sudoRole
> sudoOption: !root_sudo
> sudoOption: ignore_local_sudoers
> sudoOption: always_set_home
> sudoOption: passprompt=Your password:          <-- notice missing quotes
> sudoOption: mail_no_perms
> sudoOption: mail_no_host
> sudoOption: runas_default=adm
> sudoOption: mail_no_user
> sudoOption: !set_logname
> sudoOption: syslog=local2
> sudoOption: mailto=root at domain.com               <-- notice missing quotes
> > User_Alias SAS = sa_user1, sa_user2, sa_user3
> > Host_Alias UNIXSERVERS = unxsrv01, unxsrv02, unxsrv03, unxsrv04,
> > Runas_Alias ADM = ra_user1
> > Cmnd_Alias SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
> >                         /usr/local/bin/tcsh, /usr/bin/rsh, \
> >                         /usr/local/bin/zsh
> Okay, this is a more compliated one and it has one small problem.
> the ldap code in sudo does not honor the 'allow all commands except..'
> notion.  But I'll discuss that in a minute, for now, lets see how the rest
> expands:
> dn: cn=SAs Role,ou=sudoers,o=example.com
> cn: SAs Role
> objectClass: top
> objectClass: sudoRole
> sudoUser: sa_user1
> sudoUser: sa_user2
> sudoUser: sa_user3
> sudoHost: unxsrv01
> sudoHost: unxsrv02
> sudoHost: unxsrv03
> sudoHost: unxsrv04
> sudoHost: unxsrv05
> sudoRunAs: ra_user1
> sudoCommand: ALL
> sudoCommand: !/usr/bin/sh                  <--- ignored: does not work
> you would think
> sudoCommand: !/usr/bin/csh                 <--- ignored: does not work
> you would think
> sudoCommand: !/usr/bin/ksh                 <--- ignored: does not work
> you would think
> sudoCommand: !/usr/local/bin/tcsh        <--- ignored: does not work like
> you would think
> sudoCommand: !/usr/bin/rsh                 <--- ignored: does not work
> you would think
> sudoCommand: !/usr/local/bin/zsh         <--- ignored: does not work like
> you would think
> Originally I wrote the ldap code to honor the !command but after reading
> sudoers manpage and doing some careful consideration I realized the option
> allowed a very false sense of security.
> For example the following command give you /usr/bin/sh even though it
> be specifically prevented.
> $ sudo env /usr/bin/sh
> $ cp /usr/bin/sh /tmp/doit; sudo /tmp/doit
> $ ln -s /usr/bin /tmp/mypath; sudo /tmp/mypath/sh
> $ sudo perl -e 'exec "/usr/bin/sh"'
> $ sftp otherhost:/usr/bin/sh /usr/local/bin/doit; sudo
> rm /usr/local/bin/doit
> $ cc smallshell.c; sudo ./a.out
> ... and the list goes on.
> Essentially there is an infinite amount of commands and permutations that
> essentially give you some sort of shell. Because of this, it does not make
> sense to allow a feature that gives the admin a false sense of security.
> As a result, the !command feature was dropped before it became generally
> available.
> So lets try a more difficult example:
> > User_Alias ADMINS = admin1, admin2, admin3, admin4, admin5
> > Host_Alias UNIXSERVERS = unxsrv01, unxsrv02, unxsrv03, unxsrv04,
> > Host_Alias LINUXSERVERS = lnxsrv01, lnxsrv02
> > Runas_Alias ADMPLUS = ra_user1, ra_user2
> > Cmnd_Alias EDITORS = /usr/bin/vi, /usr/bin/view, /usr/local/bin/nedit,
> /usr/local/bin/less, /usr/local/bin/emacs \
> > /bin/more, /usr/local/bin/vim, /usr/local/bin/view
> > Cmnd_Alias SUCOM = /usr/bin/dump, /usr/bin/shutdown
> After expansion should translate to:
> dn: cn=AdminsRole, ou=sudoers, o=example.com
> cn: AdminsRole
> description: This is the role that allows admins to do almost everything
> objectClass: top
> objectClass: sudoRole
> sudoUser: admin1
> sudoUser: admin2
> sudoUser: admin3
> sudoUser: admin4
> sudoUser: admin5
> sudoHost: unxsrv01
> sudoHost: unxsrv02
> sudoHost: unxsrv03
> sudoHost: unxsrv04
> sudoHost: unxsrv05
> sudoHost: lnxsrv01
> sudoHost: lnxsrv02
> sudoRunAs: ra_user1
> sudoRunAs: ra_user2
> sudoCommand: ALL
> This entry is pretty short.  In real life, sudoHost might be 50 or more
> hosts. In some cases it becomes easier to read if you compress the Hosts
> into a couple of netgroups.  Or if netgroups are unavailable on all
> say 47 are part of NIS and 3 arent, then list a netgroup that matches the
> and then add in the remaining three hosts that are outside of NIS.  Still
> another option is to list a network matching pattern or a hostname
> pattern.  Also if this role is for all host, then the keyword "ALL" should
> suffice.
> Even if the sudoHost cannot be made any simpler, most LDAP iplementations
> allow a fairly large ammount of attributes.  (For example, Novell
> allows way more than a thousand attributes on a single entry or
> Pretty good so far, except that we have not addressed the last parts of
> line
> Here is the rub, currently as implemented in 1.6.8b1, the nopasswd &
> options modify the entire role (meaning in this case, all of the
> cn=AdminsRole entry).
> So you could as the attribute
> sudoOption: !authenticate
> But then no passwords are required for those users, regarless if which
> command they specify.
> Similarly you could add the attribute
> sudoOption: noexec
> But if you wanted exec to work on some commands, then you still have a
> problem.
> Looks like for this next to map perfectly, I will have to add some code.
> Let me get back to you on the last part.
> I hope the previous information before this snag was helpfull though.
>  -Aaron
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users

More information about the sudo-users mailing list