[Apologies for bouncing your mails. Fixed now.]
> The core issue being that it is possible to run pen with remote
> control from untrusted hosts (or any host), should the administrator so
> desire.
Agreed. I did think of limiting the control-socket to 127.0.0.1:XX
but that a) reduces flexibility and b) still isn't sufficient to
prevent a local user to run commands.
To my mind there are two issues here:
1. Anybody that can connect to the control socket can do "things".
2. The are "things" that can be done which result in potential
security problems.
The ideal solution would be to require password authentication
in addition to the socket connectivity. This would let you,
potentially, run with a control-socket wide open, but still restrict
malicious connections.
(Obviously from localhost you'd want to have a password in an
unreadable file, to avoid it from being read via vi, or similar.)
The second problem of allowing file overwrites via the "write"
primitive could be solved via chrooting, dropping privileges to
nobody, or disabling the primitive unless it appears in the config
file.
I'm not sure how generally useful all the primitives are, but I could
see the case for only allowing some primitives to work from a config
file and not interactively. Similarly I could see dropping privileges
from root to "pen" and chrooting to "/var/run/pen" would avoid any
file overwrites from happening - because the deamon would simply not
have the permission to do so.
As you say the .CGI script is perhaps best avoided, but the
documentation should certainly mention potential concerns with
the use of a control socket.
I've requested CVE IDs for the various issues, and will update
if/when I receive them.
Steve
--
http://www.steve.org.uk/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
