kadmin ignoring target column ?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

kadmin ignoring target column ?

Laura Smith
Hi,

I am trying to create a suitably restricted user for use with configuration automation (SaltStack ).  My line looks like the following :

saltstack/[hidden email] ADMCIL nfs/*@EXAMPLE.COM

I have edited kadm5.acl and restarted kadmind, however list_princs returns a list of all principals, not just nfs/* ?

If I remove the target column (i.e. saltstack/[hidden email] ADMCIL)  and restart kadmind, then ADMCIL operates as expected (blocks list_princs entirely).

What am I missing ?

Laura

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Russ Allbery-2
Laura Smith <[hidden email]> writes:

> I am trying to create a suitably restricted user for use with
> configuration automation (SaltStack ).  My line looks like the following:

> saltstack/[hidden email] ADMCIL nfs/*@EXAMPLE.COM

> I have edited kadm5.acl and restarted kadmind, however list_princs
> returns a list of all principals, not just nfs/* ?

> If I remove the target column (i.e. saltstack/[hidden email] ADMCIL) 
> and restart kadmind, then ADMCIL operates as expected (blocks
> list_princs entirely).

I don't believe the "l" permission supports the target field.  I think
it's all or nothing: either you can list all principals or you can't.  The
man page for kadm5.acl seems to support that:

  l  [Dis]allows the listing of all principals or policies

--
Russ Allbery ([hidden email])             <https://www.eyrie.org/~eagle/>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Laura Smith



Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 12, 2020 7:17 PM, Russ Allbery <[hidden email]> wrote:

> Laura Smith [hidden email] writes:
>
> > I am trying to create a suitably restricted user for use with
> > configuration automation (SaltStack ).  My line looks like the following:
>
> > saltstack/[hidden email] ADMCIL nfs/*@EXAMPLE.COM
>
> > I have edited kadm5.acl and restarted kadmind, however list_princs
> > returns a list of all principals, not just nfs/* ?
>
> > If I remove the target column (i.e. saltstack/[hidden email] ADMCIL) 
> > and restart kadmind, then ADMCIL operates as expected (blocks
> > list_princs entirely).
>
> I don't believe the "l" permission supports the target field. I think
> it's all or nothing: either you can list all principals or you can't. The
> man page for kadm5.acl seems to support that:
>
> l [Dis]allows the listing of all principals or policies
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Russ Allbery ([hidden email]) https://www.eyrie.org/~eagle/

Hi Russ,

Fair enough, but I can still add/delete principals even with ADMCIL (e.g. I could add test/test, which should not be possible with a nfs/* restriction ?)

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Greg Hudson
In reply to this post by Laura Smith
On 1/12/20 2:01 PM, Laura Smith wrote:
> I am trying to create a suitably restricted user for use with configuration automation (SaltStack ).  My line looks like the following :
>
> saltstack/[hidden email] ADMCIL nfs/*@EXAMPLE.COM

The man page says:

    If the character is *upper-case*, then the operation
    is disallowed.  If the character is *lower-case*, then the operation
    is permitted.

Since all of the permission bits are in uppercase, that line should
grant no permissions to saltstack/admin.  When I test with a similar
line it doesn't appear to grant add permissions for any principals.  Is
there a previous line that matches the client saltstack/admin, and
grants full add permissions?  kadmind stops when it finds the first ACL
line matching the client and target; it doesn't continue on to look for
a more specific match.

With the current sources, if I do "make testrealm" and then change the
first line of testdir/acl to read:

    user/[hidden email] admcil nfs/*@KRBTEST.COM

then I get the expected results for user/admin:

    kadmin:  listprincs
    get_principals: Operation requires ``list'' privilege while
retrieving list.
    kadmin:  addprinc -pw pw nfs/test
    No policy specified for nfs/[hidden email]; defaulting to no policy
    Principal "nfs/[hidden email]" created.
    kadmin:  addprinc -pw pw test/test
    No policy specified for test/[hidden email]; defaulting to no policy
    add_principal: Operation requires ``add'' privilege while creating
"test/[hidden email]".

(It turns out that operations with no target principal, including
listprincs, fail if there is any target pattern for the entry besides
"*".  This isn't really documented.)

Also, what version of krb5 is running on the KDC?  The kadmind ACL code
changed substantially in 1.16 (though it shouldn't have affected this
behavior), so if you're running an earlier version than that I might be
able to re-test with older code.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Laura Smith



Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 12, 2020 10:48 PM, Greg Hudson <[hidden email]> wrote:

> On 1/12/20 2:01 PM, Laura Smith wrote:

>
> Since all of the permission bits are in uppercase, that line should
> grant no permissions to saltstack/admin. When I test with a similar
> line it doesn't appear to grant add permissions for any principals. Is
> there a previous line that matches the client saltstack/admin, and
> grants full add permissions? kadmind stops when it finds the first ACL
> line matching the client and target; it doesn't continue on to look for
> a more specific match.

Am aware of the list ordering requirement, and to that extent the ACL entry in question was quite deliberately placed at the top.

>
> With the current sources, if I do "make testrealm" and then change the
> first line of testdir/acl to read:
>
> user/[hidden email] admcil nfs/@KRBTEST.COM
> then I get the expected results for user/admin:
> kadmin: listprincs
> get_principals: Operation requires `list'' privilege while retrieving list. kadmin: addprinc -pw pw nfs/test No policy specified for nfs/[hidden email]; defaulting to no policy Principal "nfs/[hidden email]" created. kadmin: addprinc -pw pw test/test No policy specified for test/[hidden email]; defaulting to no policy add_principal: Operation requires`add'' privilege while creating
> "test/[hidden email]".
> (It turns out that operations with no target principal, including
> listprincs, fail if there is any target pattern for the entry besides
> "". This isn't really documented.)
>

admcil nfs/@KRBTEST.COM, are you saying I should not be putting the wildcard asterisk after nfs/ ?

> Also, what version of krb5 is running on the KDC? The kadmind ACL code
> changed substantially in 1.16 (though it shouldn't have affected this
> behavior), so if you're running an earlier version than that I might be
> able to re-test with older code.

Running 1.17 on Alpine Linux 3.10.3



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Greg Hudson
On 1/13/20 3:44 AM, Laura Smith wrote:
> Am aware of the list ordering requirement, and to that extent the ACL entry in question was quite deliberately placed at the top.

kadmind will continue on if the operation's target doesn't match the
entry's target.  So if you have a later entry for, say, "*/admin *",
then the line "saltstack/admin ADMCIL nfs/*" would serve to deny access
to nfs/* principals (because of the uppercase permission bits), but
would have no effect on other target principals, or on operations with
no target like list_principals.

The documentation could probably be clarified here; it talks about "the
first matching entry", but doesn't say what has to match.

> admcil nfs/@KRBTEST.COM, are you saying I should not be putting the wildcard asterisk after nfs/ ?

The wildcard asterix was there in the mail I sent out (I checked my
outgoing mail), but was apparently mangled by a piece of email software.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Laura Smith
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 4:19 PM, Greg Hudson <[hidden email]> wrote:

> On 1/13/20 3:44 AM, Laura Smith wrote:
>
> > Am aware of the list ordering requirement, and to that extent the ACL entry in question was quite deliberately placed at the top.
>
> kadmind will continue on if the operation's target doesn't match the
> entry's target. So if you have a later entry for, say, "/admin ",
> then the line "saltstack/admin ADMCIL nfs/" would serve to deny access
> to nfs/ principals (because of the uppercase permission bits), butwould have no effect on other target principals, or on operations with
> no target like list_principals.
>
> The documentation could probably be clarified here; it talks about "the
> first matching entry", but doesn't say what has to match.

Aah, so are we saying I should try something like :
saltstack/admin admcil nfs/*
saltstack/admin ADMCIL *

Bescially my end goal is to allow saltstack/admin to do what it likes (within reason) for nfs/* but keep it well away from anything more "important" (such as */admin).


>
> > admcil nfs/@KRBTEST.COM, are you saying I should not be putting the wildcard asterisk after nfs/ ?
>
> The wildcard asterix was there in the mail I sent out (I checked my
> outgoing mail), but was apparently mangled by a piece of email software.

Yes, you're right. Have read your original and indeed asterisk is there.


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Kenneth MacDonald
Laura,

If you can change the name of the principal Salt is using, then your
authorisation rules would not require one to deny it any other
permissions.  The "admin" word isn't required to grant admin type
permissions.

For example if you changed it to "saltstack/salt.admin" you'd only
require,

saltstack/salt.admin admcil */nfs

Cheers,

Kenny.

On Mon, 2020-01-13 at 16:54 +0000, Laura Smith wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, January 13, 2020 4:19 PM, Greg Hudson <[hidden email]>
> wrote:
>
> > On 1/13/20 3:44 AM, Laura Smith wrote:
> >
> > > Am aware of the list ordering requirement, and to that extent the
> > > ACL entry in question was quite deliberately placed at the top.
> >
> > kadmind will continue on if the operation's target doesn't match
> > the
> > entry's target. So if you have a later entry for, say, "/admin ",
> > then the line "saltstack/admin ADMCIL nfs/" would serve to deny
> > access
> > to nfs/ principals (because of the uppercase permission bits),
> > butwould have no effect on other target principals, or on
> > operations with
> > no target like list_principals.
> >
> > The documentation could probably be clarified here; it talks about
> > "the
> > first matching entry", but doesn't say what has to match.
>
> Aah, so are we saying I should try something like :
> saltstack/admin admcil nfs/*
> saltstack/admin ADMCIL *
>
> Bescially my end goal is to allow saltstack/admin to do what it likes
> (within reason) for nfs/* but keep it well away from anything more
> "important" (such as */admin).
>
>
> >
> > > admcil nfs/@KRBTEST.COM, are you saying I should not be putting
> > > the wildcard asterisk after nfs/ ?
> >
> > The wildcard asterix was there in the mail I sent out (I checked my
> > outgoing mail), but was apparently mangled by a piece of email
> > software.
>
> Yes, you're right. Have read your original and indeed asterisk is
> there.
>
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos


--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: kadmin ignoring target column ?

Laura Smith
Kenny,

Sounds like a cunning plan ! Will go experiment.

Thanks

Laura

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 5:23 PM, Kenneth MacDonald <[hidden email]> wrote:

> Laura,
>
> If you can change the name of the principal Salt is using, then your
> authorisation rules would not require one to deny it any other
> permissions. The "admin" word isn't required to grant admin type
> permissions.
>
> For example if you changed it to "saltstack/salt.admin" you'd only
> require,
>
> saltstack/salt.admin admcil */nfs
>
> Cheers,
>
> Kenny.
>
> On Mon, 2020-01-13 at 16:54 +0000, Laura Smith wrote:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Monday, January 13, 2020 4:19 PM, Greg Hudson [hidden email]
> > wrote:
> >
> > > On 1/13/20 3:44 AM, Laura Smith wrote:
> > >
> > > > Am aware of the list ordering requirement, and to that extent the
> > > > ACL entry in question was quite deliberately placed at the top.
> > >
> > > kadmind will continue on if the operation's target doesn't match
> > > the
> > > entry's target. So if you have a later entry for, say, "/admin ",
> > > then the line "saltstack/admin ADMCIL nfs/" would serve to deny
> > > access
> > > to nfs/ principals (because of the uppercase permission bits),
> > > butwould have no effect on other target principals, or on
> > > operations with
> > > no target like list_principals.
> > > The documentation could probably be clarified here; it talks about
> > > "the
> > > first matching entry", but doesn't say what has to match.
> >
> > Aah, so are we saying I should try something like :
> > saltstack/admin admcil nfs/*
> > saltstack/admin ADMCIL *
> > Bescially my end goal is to allow saltstack/admin to do what it likes
> > (within reason) for nfs/* but keep it well away from anything more
> > "important" (such as */admin).
> >
> > > > admcil nfs/@KRBTEST.COM, are you saying I should not be putting
> > > > the wildcard asterisk after nfs/ ?
> > >
> > > The wildcard asterix was there in the mail I sent out (I checked my
> > > outgoing mail), but was apparently mangled by a piece of email
> > > software.
> >
> > Yes, you're right. Have read your original and indeed asterisk is
> > there.
> >
> > Kerberos mailing list [hidden email]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos