Ldif format

[Galen Johnson]

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 might
be a typo or two)  I suspect the sudoers2ldiff script needs to be rewritten.
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 magic
name used by sudo for the global default options.  Notice the missing quotes
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, unxsrv05
> 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
> SAS UNIXSERVERS = (ADM) ALL, !SHELLS

Okay, this is a more compliated one and it has one small problem.  Currently
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 like
you would think

sudoCommand: !/usr/bin/csh                 <--- ignored: does not work like
you would think

sudoCommand: !/usr/bin/ksh                 <--- ignored: does not work like
you would think

sudoCommand: !/usr/local/bin/tcsh        <--- ignored: does not work like
you would think

sudoCommand: !/usr/bin/rsh                 <--- ignored: does not work like
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 the
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 would
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 /usr/local/bin/doit;
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, unxsrv05
> 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
> ADMINS LINUXSERVERS, UNIXSERVERS=(ADMPLUS) ALL, NOEXEC:EDITORS, !SHELLS,
NOPASSWD:SUCOM

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 systems,
say 47 are part of NIS and 3 arent, then list a netgroup that matches the 47
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 matching
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 eDirectory
allows way more than a thousand attributes on a single entry or "sudoRole")

Pretty good so far, except that we have not addressed the last parts of the
line
> .... NOEXEC:EDITORS, !SHELLS, NOPASSWD:SUCOM

Here is the rub, currently as implemented in 1.6.8b1, the nopasswd & noexec
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