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 |