[36346] in Kerberos
Re: New remctl ACL scheme and execution of external ACL checking
daemon@ATHENA.MIT.EDU (=?windows-1252?Q?R=E9mi_Ferrand?=)
Wed Aug 6 12:01:42 2014
Message-ID: <53E25144.5090809@cc.in2p3.fr>
Date: Wed, 06 Aug 2014 18:01:08 +0200
From: =?windows-1252?Q?R=E9mi_Ferrand?= <remi.ferrand@cc.in2p3.fr>
MIME-Version: 1.0
To: Russ Allbery <eagle@eyrie.org>
In-Reply-To: <53E0FE7B.4020201@cc.in2p3.fr>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============1174826050=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1174826050==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms090103010403020808000201"
This is a cryptographically signed message in MIME format.
--------------ms090103010403020808000201
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
On 05/08/2014 17:55, R=E9mi Ferrand wrote:
> Sorry for the spam, afterwards I realized that this was more=20
> appropriate to open a new thread for this very subject.
>
> Regards
>
> R=E9mi
>
>
> On 17/07/2014 14:22, R=E9mi Ferrand wrote:
>>
>> * REMCTL-8: Add support for external ACL checking programs. If the
>> program exits with a zero status, access is granted. If it exits 1,
>> access is not granted but checking continues. If it exits with any
>> other exit status, access is not granted and checking aborts. Ideally,=
>> for writing generic ACL checking programs, the program should get the
>> type and service of the remctl command as well as any arguments.
>> However, it would also be good to support passing other arguments into=
>> the program as specified in the ACL file.
>>
>
> I've started to think about this feature and I think that this could=20
> be a great enhancement to be able to access to requested command,=20
> subcommand and args in the "acl_check_" functions (I guess that by=20
> "type and service of the remctl command as well as any arguments" you=20
> meant "command, subcommand and args", didn't you ?)
>
>
> I've created https://github.com/rra/remctl/pull/2 as a proposal but=20
> this could be a little "na=EFve" since it was very straightforward.
> This should be more considered as a "discussion starter" about how to=20
> grant access to command, subcommand and args to "acl_check_" functions.=
>
Using my previous patch I've created a "first version" of the external=20
acl checking support here :=20
https://github.com/ccin2p3/remctl/commit/fefb9f7820961bfef8f98dee8256bd4d=
86e19b47.
Same as my previous patch, this commit should be considered as a way to=20
initiate a discussion about how this external ACL checking support=20
should be implemented.
>
> Talking about the support for external ACL checking programs,
> for now my idea is to have a configuration line like:
>
>
> testcmd ALL /usr/bin/myprogram.pl exec_extra_arg=3D"--arg1 --arg2=20
> --arg-with-value=3D'foo'" exec:/path/to/acl_checking_command.pl
>
>
> with the new "exec" (or something like this) ACL scheme that would=20
> execute the external program "/path/to/acl_checking_command.pl" and=20
> check for its return code to allow/deny access or continue ACL=20
> processing.
>
>
> My idea was that the program "/path/to/acl_checking_command.pl" would=20
> always receive those arguments:
>
> --user=3D"remote user authenticated throw gssapi"
> --command=3D"requested command"
> --subcommand=3D"requested subcommand" (if subcommand is not NULL)
>
> (people that, in the future, would write external validation scripts=20
> MUST support those options)
This is not the way I finally choose:
* To propagate command, subcommand and user ... I've used environment as =
that's done in "server/process.c".
* Remote user supplied arguments are passed as arguments to the external =
ACL checking program.
For the special case where STDIN should be used with the *stdin* option, =
my idea was to supply STDIN to the external ACL checking program (as it=20
would be done to the final program) ... this could allow very deep=20
inspection about what is passed to the final program.
>
>
> and if option "exec_extra_arg" is used in configurationn file, then=20
> those extra arguments should be appended to previous mandatory ones,=20
> which could lead to the final execution of
>
The main problem I have is about supplying extra arguments in the=20
remctld configuration file ...
If I create a new option "exec_extra_arg", this will be a problem when=20
there will be multiple ACL that uses "exec" in the same rule, as in:
testcmd ALL /usr/bin/myprogram.pl exec_extra_arg=3D"--arg1 --arg2"=20
exec:/path/to/acl_checking_command.pl=20
exec:/path/to/other/acl_checking_command.pl
For now, I couldn't find a good way to specify those extra arguments, if =
anyone has an idea about it, just say it :-)
Cheers
R=E9mi
--------------ms090103010403020808000201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIczCC
A7YwggKeoAMCAQICAQMwDQYJKoZIhvcNAQEFBQAwLDELMAkGA1UEBhMCRlIxDTALBgNVBAoT
BENOUlMxDjAMBgNVBAMTBUNOUlMyMB4XDTA5MDEyMTA5MDM1MloXDTI5MDEyMDA5MDM1Mlow
NTELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFzAVBgNVBAMTDkNOUlMyLVN0YW5kYXJk
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnKlkarQHIxnDvggIxOIqXe3UKN7+
P6DtkkRrFkc1EzeNdKn1TYPkBRuPCGFM3ndb16n/u2Wdyaw8D/GJe5MioEcPXwa+jnigC3nX
QmVhcmOSQIpbZxD61ic+2HdNHnnbb0sSAFJY4thCBbIzN3fgjWwdvPj28pRYJfeC2YbZXPPY
Ls39cIkEh+850SrYkoxpLxxSZfpgjxB/zI/5XC4U7UyL4J03uNI8lMpQ/UF63vY87K7svVwW
3bDwc5l6gf87M9IAnk2Mxls4LjPDdobKclTbLeIQ/ZJQaJOE7XepiWlRhevglKP5lwgRjCTw
D7o4tCzW12xOY/60MZ/vj6ZapQIDAQABo4HZMIHWMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFBHj2dFSRxtZsTwbeGZr9KGI7QpbMFQGA1UdIwRNMEuAFFCXtg33rDMXr/EdRjxrO/8A
oOXloTCkLjAsMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEOMAwGA1UEAxMFQ05SUzKC
AQAwDgYDVR0PAQH/BAQDAgEGMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9jcmxzLnNlcnZp
Y2VzLmNucnMuZnIvQ05SUzIvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAT+njF+ZM
J/UXalBV6u7PTKq97izddj5ZoC8LaInaQ9AeHSxrEvlnE55lK6SE0jHPgqDK7yLoEGzpzxd8
rK2HhUyK4dV7TObZDrKh5CmeIK8PPnu5fyRMMuCI/nrarBZgoXWuiZyKZp2Uun6rDiAj7ffH
hF2CSBTexNSwxU4sh9SNAxEvNtUpb66ZZxkMjW1aIN/Rn8bLr1XuC8qxWw/vXHT080aJY0d+
LM6/yDANAEb2GOZsPzB+kG4QjR85Sc+TaevInsJnc69Ki/Z8Qijdpd3tr8lVG2Q/VLxhJhDr
kdXp9+7Q9gsL+qaQ3WD0QJ0Lp5z4zi8hOP6rBr/aDXf6ZzCCBLUwggOdoAMCAQICAncXMA0G
CSqGSIb3DQEBBQUAMDUxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5D
TlJTMi1TdGFuZGFyZDAeFw0xMzEyMTYwOTU2NTRaFw0xNTEyMTYwOTU2NTRaMG4xCzAJBgNV
BAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVU1I2NDAyMRUwEwYDVQQDEwxSZW1p
IEZlcnJhbmQxJzAlBgkqhkiG9w0BCQEWGHJlbWkuZmVycmFuZEBjYy5pbjJwMy5mcjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKX2GNdpXGGVVTHINm0/jbX4GhT7ahVCNlJA
vv0cg5oGxw8sJRNKdM6AWvPz7Q93FkxFy9dcPL3R9deXo4FgAF+RCbDtnDorPCqo+Zmk+2M/
FsbGKPcauVsy8wWua3l08GcDLICwYA/urUeI/obeo2xTbhT0FQTNHKvYJPGVTSxEZ332yNBp
yapLOvlg8hMjruFXUQ3cSCrt5fCAH/MJX9klvA0cDBJ79mbss9O+S9YpMsyHTfESoVVuOIE3
y8ulpioMyL/JKAzsQRxTvXY8l0fgITCaMHEAv1CTg2aSaY9+RvyFXZEWeF9Gkx20XN1TNutq
yzRoLLQ7BRqVRceyR5sCAwEAAaOCAZQwggGQMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMA4GA1UdDwEB/wQEAwIF4DB6BglghkgBhvhCAQ0EbRZrQ2VydGlmaWNhdCBDTlJT
Mi1TdGFuZGFyZC4gUG91ciB0b3V0ZSBpbmZvcm1hdGlvbiBzZSByZXBvcnRlciDgIGh0dHA6
Ly9pZ2Muc2VydmljZXMuY25ycy5mci9DTlJTMi1TdGFuZGFyZC8wHQYDVR0OBBYEFHdU+LuD
UWrGGhG87mM7ESwUh9IYMFQGA1UdIwRNMEuAFBHj2dFSRxtZsTwbeGZr9KGI7QpboTCkLjAs
MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEOMAwGA1UEAxMFQ05SUzKCAQMwIwYDVR0R
BBwwGoEYcmVtaS5mZXJyYW5kQGNjLmluMnAzLmZyMEcGA1UdHwRAMD4wPKA6oDiGNmh0dHA6
Ly9jcmxzLnNlcnZpY2VzLmNucnMuZnIvQ05SUzItU3RhbmRhcmQvZ2V0ZGVyLmNybDANBgkq
hkiG9w0BAQUFAAOCAQEAPaW7JB0REr9b8m95MR9FOqa0CusPLcB7ehvms+WhkTPWNYKAbB4R
RUbIiD796zs7pefwPQh7GBvVEaTWIN8bLnSIkfb7cXooH2XLHToUjuMVMrnabfKZ4bWLbA/3
rczLXBTi4/rDh+sHBEOx0jlCAGbKfvy6IeGFJTYTVEeAtrxofXRppf2RM5K7lGuMagvcDu49
HXCstx5wdoHYAwzwBiHhvCmBRQ3mSpHnH+KewJ+LUSeD+xv0Q95ElCr7cPJraI9J+6BFCEoh
7Gy2O9gk51HEVf98JYXdkfVqhOGxegVN+dSJznif8FL/vWXF6KgCTqST1iEv8gzUDAH3zdpJ
jzGCAsswggLHAgEBMDswNTELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFzAVBgNVBAMT
DkNOUlMyLVN0YW5kYXJkAgJ3FzAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MDYxNjAxMDhaMCMGCSqGSIb3DQEJBDEWBBRo
CZzF/O6Ru+jszBr9eKXuvkAhKjBKBgkrBgEEAYI3EAQxPTA7MDUxCzAJBgNVBAYTAkZSMQ0w
CwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5DTlJTMi1TdGFuZGFyZAICdxcwTAYLKoZIhvcNAQkQ
AgsxPaA7MDUxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5DTlJTMi1T
dGFuZGFyZAICdxcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAEC
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQB9voYIL+pO4lpy8C8XbolgilnmkE+v
B+FgxlP4SAwMRQQwsUvZNGIFsNlYDhOM5520dN6S4TVi+f/R0/JWwHcv1NfAr+H+Hcoe5QfR
Oy/CeSg+yuUYg3xHU1B6ezVu4h9ROQH+Xz/YwPVeKmhvuNuBo24rP4fc8o+5wPcRcxqawXNu
k1Ei9zpwR2OoEWMcD9j3T6dEbwLJJQTq3KdJ0lPm9Fn03qXKXiL3iWZhmFzmdQo8ZzDh8yEX
nPl6waScyYbcA1fECboqyfaKkk/nE1LgPyiUNfLPGPCst0MNGWTNczSyLWinWcOEBZqYaq+n
DTnSKMBpN6NtQ1DgY1hEk1XXAAAAAAAA
--------------ms090103010403020808000201--
--===============1174826050==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1174826050==--
