mirror of
https://github.com/xcat2/confluent.git
synced 2024-11-23 18:11:15 +00:00
44 lines
2.3 KiB
Plaintext
44 lines
2.3 KiB
Plaintext
Try to forbid running as root. If started as root, require a username to
|
|
switch to. The latter will probably be required for operations involving
|
|
privileged ports or multicast. Additionally, be SELinux friendly.
|
|
|
|
Things that tend to require root try to do without or handle in other ways:
|
|
-writing new dhcpd config and/or dns config
|
|
-DNS updates keep DDNS scheme, have a helper script to create an
|
|
amenable named config structure for common case on deploy. Dynamic
|
|
zone creation would require something more.
|
|
-dhcp - require less precise dhcp configuration. Have a script to
|
|
generate things with dynamic range and such. May not be viable
|
|
for appliance-style deployment.
|
|
-perhaps implement sudo type escalation for key utilities as required
|
|
-copycds mount
|
|
-switch to libguestfs
|
|
-xdsh/xdcp
|
|
-Try to get by with psh/pscp style usage where that relationship is
|
|
entirely outside the daemon.
|
|
-binding low ports like SLP or bootps or setting multicast/broadcast
|
|
-bind early, then drop privilege
|
|
|
|
|
|
Some experiments were tried with capabilities, but the logistics of meaningful
|
|
restriction in the context of running under an interpreter like python has not
|
|
been figured out. Once python is exec()ed, pythons setcap attributes take
|
|
over. This would require a much less secure python or a private python
|
|
interpreter copy. So we will have to at least start as root and drop privelege
|
|
after setting only the things we care about up (binding socket, setting
|
|
multicast).
|
|
|
|
Should the time come for arbitrary executable invocation as described in config
|
|
comes about, such facilities will be part of a feature that would be disabled
|
|
by default. Two examples would be template fill in feature and script backend
|
|
for consoles.
|
|
|
|
When starting to service PXE, PXE and http support by default. However, for
|
|
more strict environments, allow https-only mode and disabling PXE. The two
|
|
might make sense to be tied together, since https bootstrap in the midst of a
|
|
PXE boot is not really benefitting from absolute security.
|
|
|
|
Auto-actuation of SLP detected entities might be enabled by default, but again
|
|
having it locked down for environments that want hard assurance that every
|
|
operation is meaningfully authenticated may make sense.
|