This section just summarizes security features of Epos documented elsewhere to assist the administrator in setting up a multi-user installation of Epos, especially in a UNIX-like environment.
Epos can be compiled in two ways; either as a simple monolithic binary or as a Text-to-Speech Control Protocol server. For technical reasons (especially the latency), it is strongly recommended to choose the latter method for most situations.
TTSCP as such includes support for user name and plain text password based authentication. At the moment, Epos doesn't implement any name space for this authentication mechanism, except for a randomly-generated server password. Thus, all connections are either completely anonymous, or authenticated at the "server" level (which can still be restricted from setting or reading specific options.)
The server password is stored in /var/run/epos.pwd
. Any process
with rights sufficient to read this file is able to authenticate as the
server over TTSCP.
For debugging purposes, it is also possible to force Epos to accept
an additional server password with the debug_password
option.
In TTSCP, a control connection can issue commands that affect any
other connection (e.g. interrupt a command in progress). To prevent
malicious use, the handle necessary to refer to a connection is
only available to the connection originator, and is generated at random.
Consequently, privacy in TTSCP relies on the properties of the underlying
network connection and on the length of the data connection handle.
Each byte of handle length carries a perplexity of six bits; reasonable
handle lengths (as controlled with the handle_size
option therefore
fall within the range 10
to 200
. Be sure to adjust
max_line_len
as well if using extremely long connection handles.
restr.ini
file
Many TTSCP options are rarely set over TTSCP, and some of them could be
used for malicious ends. In these cases, the administrator may restrict
their use in the restr.ini
as described in
the respective section. Note especially that unlisted options can
be set freely, and the default restr.ini
file as distributed with Epos
may occasionally omit a slightly dangerous option. Therefore,
you may want to grep out a list of all options and to leave out
only options you're going to treat as necessary for users and harmless
for the server. On the other hand, almost no options affect the security
directly, because they're only set within the context of the current
TTSCP connection, and the few exceptions are unlikely to have been overlooked.
At the moment, any TTSCP client is capable of writing arbitrary waveform data
to the local soundcard. If you consider this a security risk, disable
the #localsound
output module by turning the localsound
option off.
TTSCP in theory offers file system based input and output modules. For example,
that allows the client to write some intermittent product to a server-side file
and then the client may decide to use it repeatedly as an input to multiple streams.
However, the name space for the files doesn't have to correspond to the file system
root of the TTSCP server. With Epos, you can configure the location of the
TTSCP name space using the
--pseudo_root_dir option.
Furthermore, writing to it is disabled by default; this restriction can be overridden
by setting the --writefs
option.
It is not recommended to run Epos as a setuid or setgid binary, not because of a known security weakness, but because of the possibility of yet unknown bugs. If necessary, Epos should run setgid to a group with minimal privileges.
Note also that the base_dir
parameter can be given to Epos on the
command-line, thus by-passing the restrictions specified in the restr.ini
file. This issue may be solved in later versions of Epos; at the moment
you have to adjust the source manually.
Instead of a privileged executable, run Epos with the desired privileges at system start-up and use a TTSCP client to control it from then on.
local_only
option
By default, the TTSCP server only binds to the loopback interface.
That way, only local users can see and use Epos. Turn off the
local_only
option to allow remote users to communicate
with Epos on your machine.
Theoretically, this security measure should not be needed, but it is very simple and thus likely to reduce the risk caused by bugs hidden in more complex corners of the Epos TTSCP implementation.