Gentoo Archives: gentoo-hardened

From: Petre Rodan <petre.rodan@××××××××××××.com>
To: Tad <tadglines@×××××××.net>
Cc: Hardened Gentoo Mail List <gentoo-hardened@g.o>
Subject: Re: [gentoo-hardened] daemontools RFC
Date: Sun, 30 Nov 2003 11:41:44
Message-Id: 20031130114139.GA29513@peter.rav.local
1 On Sun, Nov 30, 2003 at 02:26:45AM -0800, Tad wrote:
2 > I like the centralized location. If each service directory where completely
3 > static I'd be happier with /etc/service. But since the supervise directory
4 > isn't static, I think /var/service is ideal. If a particular service
5 > requires a context other than svc_run_t, then a more explicit rule (e.g.
6 > /var/service/qmail-smtp/run) will get the job done.
7 >
8 > I would, however, make a few slight changes to the actual labels used.
9 > The supervise directories are not created at install time but automatically.
10 > The only way to get the files labled properl at runtime (baring code
11 > changes) is to use the handy file_type_autp_trans(). So what I would do is
12 > use svc_dir_t to label the supervise dir and label the files svc_file_t and
13 > svc_pipe_t (easier to differentiate from svc_fifo_t).
14 >
15 > The file_type_auto_trans rules would be:
16 > file_type_auto_trans(svc_t, svc_dir_t, svc_file_t, file)
17 > file_type_auto_trans(svc_t, svc_dir_t, svc_pipe_t, fifo_file)
18 >
19 > I realize it isn't quite as fine grained as what you are proposing, but it
20 > ensures proper labeling on first run.
21
22 this is a good idea. do you have made actual rules i can check out on the test system? these kind of changes will somewhat propagate in ucspi-tcp and others.
23
24 > BTW, what do you think about treating svc_t similar to initrc_t with its own
25 > run_svc. The run_svc would exec svc into the proper context. Initrc_t has a
26 > lot of priviledges and it makes me nervous running svc in that domain.
27 > If we put svc in it's own domain, we can create service_domain macros that
28 > are similar to daemon_domain but relevant to svc and containing only
29 > permissions needed for running a service under svc/supervise.
30
31 the thing is that in gentoo daemontools are run from /etc/init.d/svscan.
32 this is the place where i make the domain_auto_trans to svc_t.
33 with the default install, supervise would be spawned directly using inittab.
34
35 i dont understand from what domain would you like to trans to svc_t.
36
37 i like the idea with new domain macros, but i don't yet have the knowledge to do it.
38
39 the important thing here would be to have a centralized daemon pool, or our selinux policies for daemons will be extremely bloated.
40
41 maybe i should have posted this on gentoo-dev ...
42
43 bye,
44 peter
45
46 >
47 > -Tad
48 >
49 > > -----Original Message-----
50 > > From: Petre Rodan [mailto:petre.rodan@××××××××××××.com]
51 > > Sent: Sunday, November 30, 2003 1:39 AM
52 > > To: Hardened Gentoo Mail List
53 > > Subject: [gentoo-hardened] daemontools RFC
54 > >
55 > >
56 > >
57 > > good morning,
58 > >
59 > > i would like to point out a small flaw in some packages that are currently
60 > > being used in portage that can make things very complicated once the
61 > > selinux policy will be used in a larger scale.
62 > >
63 > > the following packages: qmail-*, djbdns, relay-ctrl, serialmail, bincimap,
64 > > slidentd, leafnode, fnord, publicfile, nullmailer (and possibly others in
65 > > the future) all have in common the dependency to daemontools.
66 > >
67 > > for those who don't use daemontools, more info about it can be found here:
68 > > http://cr.yp.to/daemontools.html
69 > >
70 > > to add a daemon to the 'supervise pool' (let's say qmail), one should make
71 > > a symlink from a $SUPERVISE_DIR/qmail-smtpd to /service/qmail-smtpd.
72 > > to start it, one must run svc -u qmail-smtpd, and so on.
73 > >
74 > > supervise will create inside $SUPERVISE_DIR/<daemon_name>/supervise/ a
75 > > lock file, two fifo files and one regular file containing status
76 > > information.
77 > > if $SUPERVISE_DIR/<daemon_name>/log directory exists, then
78 > > $SUPERVISE_DIR/<daemon_name>/log/supervise/ will have the same structure
79 > > as above.
80 > >
81 > > all this maintenance can be very easy with sys-apps/supervise-scripts
82 > > (with one condition i will explain later).
83 > >
84 > > my problem is that every package (at least those i've been using) has it's
85 > > own $SUPERVISE_DIR. for qmail is /var/qmail/supervise/qmail-*, for djb-
86 > > cache the default is /{etc,var}/dnscache, for tinydns is
87 > > /{etc,var}/tinydns, for publicfile is /home/publicfile?/{ftpd,httpd} (if I
88 > > remember correctly)
89 > >
90 > > i suggest to make a common denominator for all the packages that use
91 > > daemontools: $SUPERVISE_DIR should allways be /var/service/<daemon_name>,
92 > > and if the user must choose this directory at install time (as in the
93 > > djbdns suite) then the default should be the same
94 > > /var/service/<daemon_name>.
95 > >
96 > > pros:
97 > >
98 > > - the file_context policy for daemontools related to the supervise
99 > > directories will have only 11 lines:
100 > >
101 > > /var/service/.* system_u:object_r:svc_svc_t
102 > > /var/service/.*/down system_u:object_r:svc_down_t
103 > > /var/service/.*/supervise/control system_u:object_r:svc_control_t
104 > > /var/service/.*/supervise/ok system_u:object_r:svc_ok_t
105 > > /var/service/.*/supervise/lock system_u:object_r:svc_lock_t
106 > > /var/service/.*/supervise/status system_u:object_r:svc_status_t
107 > > /var/service/.*/log/status system_u:object_r:svc_logstatus_t
108 > > # environment variables
109 > > /var/service/.*/env(/.*)? system_u:object_r:svc_env_t
110 > > # starting scripts
111 > > /var/service/.*/run.* system_u:object_r:svc_run_t
112 > > /var/service/.*/log/run system_u:object_r:svc_run_t
113 > > # log
114 > > /var/service/.*/log/main(/.*)? system_u:object_r:svc_log_t
115 > >
116 > > - administration of daemons is much simpler. supervise-scripts can add
117 > > and remove daemons (because he only uses /var/service as daemon
118 > > repository).
119 > >
120 > > cons:
121 > >
122 > > - the file_context policy for supported daemons will be (11 *
123 > > no_of_supported_daemons)
124 > > - new ebuils should move the contents of $OLD_SUPERVISE_DIR to
125 > > /var/service/<daemon_name> and create a link to /service/<daemon_name>
126 > >
127 > > what do you think about this?
128 > >
129 > > i'm sorry to tell you, but the policies that i've sent to buzilla assume
130 > > the /var/service/<daemon_name> location. i've never used the funny
131 > > locations packages want to install $SUPERVISE_DIR in. imagine having
132 > > /etc/init.d/apache in /home/apache, /etc/init.d/squid in /var/lib/squid.
133 > >
134 > > the policies can be made to comply with the current $SUPERVISE_DIR
135 > > locations, but i will not reply to funny questions regarding the number of
136 > > file_contexts in my rules :)
137 > >
138 > > bye,
139 > > peter
140 > >
141 >
142
143 --
144
145 Petre Rodan
146 Senior Network Engineer
147 GeCAD Software - RAV Division
148
149 ----------------------------------------------------------------------
150 Tel/Fax: +40-21-321-7803
151 Hotline: +40-21-321-7859
152
153 This message is confidential. It may also be privileged or otherwise
154 protected by work product immunity or other legal rules. It may contain
155 personal views which are not the views of the GeCAD unless specifically
156 stated.
157 If you have received it in error, please delete it from your system.
158 Do not use, copy or disclose the information in any way nor act in
159 reliance on it and notify the sender immediately.
160
161 --
162 gentoo-hardened@g.o mailing list

Replies

Subject Author
RE: [gentoo-hardened] daemontools RFC Tad <tadglines@×××××××.net>