1 |
On Sunday, November 30, 2003 at 3:42 AM, Petre Rodan wrote: |
2 |
> On Sun, Nov 30, 2003 at 02:26:45AM -0800, Tad wrote: |
3 |
> > I like the centralized location. If each service directory where |
4 |
> completely |
5 |
> > static I'd be happier with /etc/service. But since the supervise |
6 |
> directory |
7 |
> > isn't static, I think /var/service is ideal. If a particular service |
8 |
> > requires a context other than svc_run_t, then a more explicit rule (e.g. |
9 |
> > /var/service/qmail-smtp/run) will get the job done. |
10 |
> > |
11 |
> > I would, however, make a few slight changes to the actual labels used. |
12 |
> > The supervise directories are not created at install time but |
13 |
> automatically. |
14 |
> > The only way to get the files labled properl at runtime (baring code |
15 |
> > changes) is to use the handy file_type_autp_trans(). So what I would do |
16 |
> is |
17 |
> > use svc_dir_t to label the supervise dir and label the files svc_file_t |
18 |
> and |
19 |
> > svc_pipe_t (easier to differentiate from svc_fifo_t). |
20 |
> > |
21 |
> > The file_type_auto_trans rules would be: |
22 |
> > file_type_auto_trans(svc_t, svc_dir_t, svc_file_t, file) |
23 |
> > file_type_auto_trans(svc_t, svc_dir_t, svc_pipe_t, fifo_file) |
24 |
> > |
25 |
> > I realize it isn't quite as fine grained as what you are proposing, but |
26 |
> it |
27 |
> > ensures proper labeling on first run. |
28 |
> |
29 |
> this is a good idea. do you have made actual rules i can check out on the |
30 |
> test system? these kind of changes will somewhat propagate in ucspi-tcp |
31 |
> and others. |
32 |
|
33 |
I have rules that do this, but they are in flux as I am rethinking how I |
34 |
want to handle ucspi-tcp. Once I have something working I'll post it. |
35 |
|
36 |
> > BTW, what do you think about treating svc_t similar to initrc_t with its |
37 |
> own |
38 |
> > run_svc. The run_svc would exec svc into the proper context. Initrc_t |
39 |
> has a |
40 |
> > lot of priviledges and it makes me nervous running svc in that domain. |
41 |
> > If we put svc in it's own domain, we can create service_domain macros |
42 |
> that |
43 |
> > are similar to daemon_domain but relevant to svc and containing only |
44 |
> > permissions needed for running a service under svc/supervise. |
45 |
> |
46 |
> the thing is that in gentoo daemontools are run from /etc/init.d/svscan. |
47 |
> this is the place where i make the domain_auto_trans to svc_t. |
48 |
> with the default install, supervise would be spawned directly using |
49 |
> inittab. |
50 |
|
51 |
The supervise processes are spawned from svscan not init. |
52 |
|
53 |
> i dont understand from what domain would you like to trans to svc_t. |
54 |
|
55 |
there would be two domain_auto_trans rules: |
56 |
|
57 |
# trans from init_rc to svc_t when svscan is run. |
58 |
domain_auto_trans(initrc_t, svc_exec_t, svc_t) |
59 |
# trans to svc_t when sysadm_t runs svc. |
60 |
Domain_auto_trans(sysadm_t, svc_exec_t, svc_t) |
61 |
|
62 |
A program similar to run_init is needed when starting services because svc |
63 |
directly exec's supervise. And supervise needs to be running in the |
64 |
system_u:system_r:svc_t context and not root:sysadm_r:svc_t. |
65 |
|
66 |
> i like the idea with new domain macros, but i don't yet have the knowledge |
67 |
> to do it. |
68 |
|
69 |
I've already started on this and will use qmail as the first test case. |
70 |
|
71 |
> the important thing here would be to have a centralized daemon pool, or |
72 |
> our selinux policies for daemons will be extremely bloated. |
73 |
|
74 |
I'm not quite sure what you mean here. |
75 |
|
76 |
> maybe i should have posted this on gentoo-dev ... |
77 |
|
78 |
Personally, I think this is the right place for this discussion. |
79 |
|
80 |
-Tad |
81 |
|
82 |
|
83 |
-- |
84 |
gentoo-hardened@g.o mailing list |