Re: [RDD] Thinking about 'RN' [wrap-up]
Looks good to me Fred. Lorne Tyndale > > On Tue, 2019-02-05 at 10:34 -0500, Fred Gleason wrote: > > What are some ways we could improve this RML? > > The user consensus as expressed here looks to be: > > 1) Add the ability to specify a specific Linux user/group to use for > running the commands (as opposed to using the values of 'AudioOwner=' > and 'AudioGroup='). > > 2) Otherwise change nothing at all. > > Any dissents? > > Cheers! > > > |-| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |-| > | A room without books is like a body without a soul. | > | | > | -- Cicero | > |-| > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN' [wrap-up]
On 2/7/19 1:18 PM, Fred Gleason wrote: > On Tue, 2019-02-05 at 10:34 -0500, Fred Gleason wrote: >> What are some ways we could improve this RML? > > The user consensus as expressed here looks to be: > > 1) Add the ability to specify a specific Linux user/group to use for > running the commands (as opposed to using the values of 'AudioOwner=' > and 'AudioGroup='). > > 2) Otherwise change nothing at all. > > Any dissents? No dissent here. This seems a decent way to handle RN. Thanks for bringing this up Fred! ~David Klann signature.asc Description: OpenPGP digital signature ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN' [wrap-up]
On Tue, 2019-02-05 at 10:34 -0500, Fred Gleason wrote: > What are some ways we could improve this RML? The user consensus as expressed here looks to be: 1) Add the ability to specify a specific Linux user/group to use for running the commands (as opposed to using the values of 'AudioOwner=' and 'AudioGroup='). 2) Otherwise change nothing at all. Any dissents? Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | A room without books is like a body without a soul. | | | | -- Cicero | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN'
On Tue, 5 Feb 2019, Fred Gleason wrote:
The 'Run Shell Command' ['RN'] RML has been part of Rivendell from the
early days of the project (it first appeared in v0.9.17, released on
1/10/2005). Its use at first glance appears straightforward: run the
specified command-line invocation. However, in actual practice, it has
proven to be one of the more fussy and difficult RMLs to make work,
mostly because of the rather byzantine way in which Rivendell processes
it: send a message to the background Rivendell service (ripcd(8) to be
precise), which then handles the actual execution. In order to avoid
privilege escalation attacks, ripcd(8) actually executes the command as
the user/group specified in the 'AudioOwner=' and 'AudioGroup='
directives in the '[Identity]' section of '/etc/rd.conf'. This has
proven in many [most?] cases to be confusing, counter-intuitive and
generally not what the user wants.
I've built a number of Rivendell machines that rely on RN commands for a
variety of different things, and very quickly decided that "AudioOwner"
and "AudioGroup" should be set to the logged-in user ("scott", in my case)
rather than a system user "rivendell".
In most cases, this resolves the permissions problems I otherwise
encounter, and makes it easier to verify that everything will work as it
should.
What are some ways we could improve this RML? One that has occurred to
me is to have it run the command as the local user who actually invoked
the RML. For example, if a user is logged in to a host as 'rd' (Linux
user, *not* Rivendell user!), run the requested Linux command as user
'rd'.
I have found that Perl scripts will not run directly from an RN command; I
have to run a bash script that invokes the Perl script.
This would have a big advantage over the current implementation in that
it does seem to be what most users intuitively expect to happen.
However, it comes with an awkward corner case: remote execution. What,
for example, would we do with an RML invocation like this:
CC some-remote-host RN /some/dangerous/operation!
This is the first time I've heard of a CC command. I've always done remote
invocations by using rmlsend from a bash script.
One Boston-area client has a Rivendell system that sends commands to
another Rivendell system at a co-owned station on Cape Cod. For him, I had
to write "rmlserver" and "rmlclient" scripts to encapsulate the UDP
packets as TCP so I could send them through an ssh tunnel.
Rob
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN'
On Tue, 2019-02-05 at 13:22 -0500, drew Roberts wrote: > Make an easy way for testing how things run when rivendell gets to > running it. > > Could we use a little script (or would we need something more?) that > does an su to 'AudioOwner' (and group?) and sets up the environment > to be what it is when riv runs the RML, then run the command and then > put things back to "normal..." > > This could be put in the /etc/sudoers.d directory so that the normal > rd user does not need a password to run it. Bonus points if it is > possible to run this in some sort of test mode that will report back > on what it would have done without doing it. > > Does this make any sense at all. It does. Basically, a 'sandbox' for testing things out. I suspect we'd need a sudoers rule for it. That could be quite difficult to implement in a distro-neutral manner (not to mention presenting some 'interesting' packaging issues). I confess that my main beef about 'RN' as it currently stands is that it is not at all intuitive, where 'intuitive' == 'works the way the user expects it to'. (See https://www.quora.com/What-is-meant-by-an-intuitive-interface for a good overview). Admittedly, different users can have different expectations. I know that if *I* walked up to a system out-of-the-blue and ran a function called 'Run Shell Command', I would expect it to do just that, using my current security context. I would *not* expect to have to first go dig up some special user/group information in some obscure configuration file somewhere. It feels ... wrong somehow. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | A room without books is like a body without a soul. | | | | -- Cicero | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN'
Fred, an alternate possibility... On Tue, Feb 5, 2019 at 10:34 AM Fred Gleason wrote: > The 'Run Shell Command' ['RN'] RML has been part of Rivendell from the > snip > In order to avoid > privilege escalation attacks, ripcd(8) actually executes the command as > the user/group specified in the 'AudioOwner=' and 'AudioGroup=' > directives in the '[Identity]' section of '/etc/rd.conf'. This has > proven in many [most?] cases to be confusing, counter-intuitive and > generally not what the user wants. > > What are some ways we could improve this RML? > Make an easy way for testing how things run when rivendell gets to running it. Could we use a little script (or would we need something more?) that does an su to 'AudioOwner' (and group?) and sets up the environment to be what it is when riv runs the RML, then run the command and then put things back to "normal..." This could be put in the /etc/sudoers.d directory so that the normal rd user does not need a password to run it. Bonus points if it is possible to run this in some sort of test mode that will report back on what it would have done without doing it. Does this make any sense at all. > > |-| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |-| > all the best, drew -- Enjoy the *Paradise Island Cam* playing *Bahamian Or Nuttin* - https://www.paradiseislandcam.com/ ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN'
On Tue, 2019-02-05 at 08:58 -0700, Lorne Tyndale wrote: > I admit that I have used the ability to run a remote script at times > and > have found it useful, I would be disappointed to see that > functionality > vanish. One could still do that with ssh(1). On the local system, you'd do: RN ssh remote_user@remote-host /my/remote/command! There'd be a bit of initial setup required (mostly, creating and populating a private/public key pair for ssh(1)), but it would give you much finer-grained control over which remote users run what. Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | A room without books is like a body without a soul. | | | | -- Cicero | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Thinking about 'RN'
Fred, I admit that I have used the ability to run a remote script at times and have found it useful, I would be disappointed to see that functionality vanish. On the other hand I can understand the challenges of the current system. What about the possibility of adding another configuration option in rd.conf to specify the local user / group for the RN RML to run scripts as? That way you could set up a workstation to have ripcd run those scripts as the logged in user or any other user on that system and leave the audio ownership separate. Of course it would make for one more step when setting up (you'd have to make sure the account listed actually exists on the workstation, etc), but it could potentially offer a way forward and provided it is set up correctly it would also offer a way to prevent a potentially malicious script (one that deletes the contents of /var/snd for example) from running at all. Lorne Tyndale > > > The 'Run Shell Command' ['RN'] RML has been part of Rivendell from the > early days of the project (it first appeared in v0.9.17, released on > 1/10/2005). Its use at first glance appears straightforward: run the > specified command-line invocation. However, in actual practice, it has > proven to be one of the more fussy and difficult RMLs to make work, > mostly because of the rather byzantine way in which Rivendell processes > it: send a message to the background Rivendell service (ripcd(8) to be > precise), which then handles the actual execution. In order to avoid > privilege escalation attacks, ripcd(8) actually executes the command as > the user/group specified in the 'AudioOwner=' and 'AudioGroup=' > directives in the '[Identity]' section of '/etc/rd.conf'. This has > proven in many [most?] cases to be confusing, counter-intuitive and > generally not what the user wants. > > What are some ways we could improve this RML? One that has occurred to > me is to have it run the command as the local user who actually invoked > the RML. For example, if a user is logged in to a host as 'rd' (Linux > user, *not* Rivendell user!), run the requested Linux command as user > 'rd'. > > This would have a big advantage over the current implementation in that > it does seem to be what most users intuitively expect to happen. > However, it comes with an awkward corner case: remote execution. What, > for example, would we do with an RML invocation like this: > > CC some-remote-host RN /some/dangerous/operation! > > What user/group should 'some-remote-host' run > '/some/dangerous/operation' as? The local user on the originating > system? That user may not even exist on the remote one! The current > 'locally logged in' user on 'some-remote-host'? Beyond the semantics of > exactly how one determines what 'locally logged in' means, suppose *no > one* is logged in? This is exactly why the current implementation > behaves the way it does: to resolve this ambiguity when handling remote > execution. > > Thus, if we want to make this change (execute 'RN' as the local user), > it means that we would have to give up the capability to do so remotely > --e.g. via the 'Command Send' ['CC'] RML. Would this be an acceptable > tradeoff? > > Cheers! > > > |-| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |-| > | Real Users never know what they want, but they always know when | > | your program doesn't deliver it. | > | | > | -- Anonymous | > |-| > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] Thinking about 'RN'
The 'Run Shell Command' ['RN'] RML has been part of Rivendell from the early days of the project (it first appeared in v0.9.17, released on 1/10/2005). Its use at first glance appears straightforward: run the specified command-line invocation. However, in actual practice, it has proven to be one of the more fussy and difficult RMLs to make work, mostly because of the rather byzantine way in which Rivendell processes it: send a message to the background Rivendell service (ripcd(8) to be precise), which then handles the actual execution. In order to avoid privilege escalation attacks, ripcd(8) actually executes the command as the user/group specified in the 'AudioOwner=' and 'AudioGroup=' directives in the '[Identity]' section of '/etc/rd.conf'. This has proven in many [most?] cases to be confusing, counter-intuitive and generally not what the user wants. What are some ways we could improve this RML? One that has occurred to me is to have it run the command as the local user who actually invoked the RML. For example, if a user is logged in to a host as 'rd' (Linux user, *not* Rivendell user!), run the requested Linux command as user 'rd'. This would have a big advantage over the current implementation in that it does seem to be what most users intuitively expect to happen. However, it comes with an awkward corner case: remote execution. What, for example, would we do with an RML invocation like this: CC some-remote-host RN /some/dangerous/operation! What user/group should 'some-remote-host' run '/some/dangerous/operation' as? The local user on the originating system? That user may not even exist on the remote one! The current 'locally logged in' user on 'some-remote-host'? Beyond the semantics of exactly how one determines what 'locally logged in' means, suppose *no one* is logged in? This is exactly why the current implementation behaves the way it does: to resolve this ambiguity when handling remote execution. Thus, if we want to make this change (execute 'RN' as the local user), it means that we would have to give up the capability to do so remotely --e.g. via the 'Command Send' ['CC'] RML. Would this be an acceptable tradeoff? Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | Real Users never know what they want, but they always know when | | your program doesn't deliver it. | | | | -- Anonymous | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
