From a93c14df4c845c04d42b2a346cc2777e2214f2d6 Mon Sep 17 00:00:00 2001 From: jbjohnso Date: Mon, 21 Apr 2014 16:01:14 -0400 Subject: [PATCH] Add some notes about security related design --- SECURITY | 43 +++++++++++++++++++++++++++++++++++++++++++ TODO | 3 +++ 2 files changed, 46 insertions(+) create mode 100644 SECURITY diff --git a/SECURITY b/SECURITY new file mode 100644 index 00000000..62cb6484 --- /dev/null +++ b/SECURITY @@ -0,0 +1,43 @@ +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. diff --git a/TODO b/TODO index 921fe425..cac0dcbf 100644 --- a/TODO +++ b/TODO @@ -25,6 +25,9 @@ 'flexdiscover' command, if possible bring an ipmi device under management by way of ipv6 to eliminate requirement for ip to be specified. Requires the polling event support (which is required for security anyway) +-Change the remote timeout behavior to yield a response, then have pluginapi + decides whether to error the response or a message indicating error in case of + multi-node request -this stack trace (happened with method was set to ""): Traceback (most recent call last):