All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@kaigai.gr.jp>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Kaigai Kohei <kaigai@ak.jp.nec.com>,
	SELinux Mail List <selinux@tycho.nsa.gov>
Subject: Re: [RFC & PATCH] inherited type definition.
Date: Tue, 19 Apr 2005 01:57:37 +0900	[thread overview]
Message-ID: <4263E701.6070009@kaigai.gr.jp> (raw)
In-Reply-To: <1113827145.28051.36.camel@moss-spartans.epoch.ncsc.mil>

Hello, Thanks for your comments.

> Thanks for updating the patch.  However,  from the discussions on the
> list, I haven't seen any clear indication that this new language
> feature:
> a) solves a real problem in a superior manner to the use of macros, and

One example is Samba, FTP and Apache combined type definition.
If we try to solve this requirement with existing macros only,
we have to describe the access-permit macros for each type
as I said in past days.

In addition, I intend to use domain inheritance for my original policy
configuration only, because it's strongly opposed to merge into upstream.
But it's useful for developing the application with setcon(), I think.
When we intend to execute a child process in separate domain from the parent,
there are some common permission such as shared-memory, and so on.
It's redandant to grant same permissions for each domain, even if it's
done by any macros. If parent-type is granted the common permission,
we can restrain redandancy and human-errors by duplication of configuration.

Sorry, above example is not real-world application like apache.
But I think the definition of relationship between types is
useful functionality for developing SELinux aware applications.


> b) is being demanded by people who are presently developing policy.

Since the existing policy has been written by macros yet, the quiet
requirement for type-inheritance is indeed natural.
But I think type-inheritance is useful for appropriate field
on developing new policy.
Of course, we can select using macros depending on circumstances.


> I'm willing to be convinced otherwise, but I just haven't seen the
> evidence for it yet.  Have you considered working on a template feature
> for the language instead, as that clearly would be beneficial?

In my understanding, template feature defines horizontal relationship of types.
e.g) the relationship of staff_t, staff_home_dir_t and staff_home_t.

Type inheritance defines vertical relationship of types.
e.g) the relationship of samba_share_t, ftp_anon_t and those combined type.

Those features provide another worth. Am I wrong ?

Thanks,
-- 
DO NOTHING IS THE WORST POLICY.
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2005-04-18 16:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-13 16:36 [RFC & PATCH] inherited type definition KaiGai Kohei
2005-03-14 13:17 ` KaiGai Kohei
2005-03-14 13:50 ` Stephen Smalley
2005-03-14 15:13   ` Luke Kenneth Casson Leighton
2005-03-14 15:22     ` Stephen Smalley
2005-03-14 16:01       ` Luke Kenneth Casson Leighton
2005-03-14 19:27         ` Valdis.Kletnieks
2005-03-14 20:10         ` Stephen Smalley
2005-03-14 17:26   ` KaiGai Kohei
2005-03-14 18:10     ` Luke Kenneth Casson Leighton
2005-03-14 18:25     ` Stephen Smalley
2005-03-15 11:50       ` KaiGai Kohei
2005-03-15 14:42         ` Stephen Smalley
2005-03-16  4:42           ` Kaigai Kohei
2005-03-16 10:00             ` Luke Kenneth Casson Leighton
2005-03-16 14:05             ` Stephen Smalley
2005-03-17  9:32               ` Kaigai Kohei
2005-03-17 13:55                 ` Stephen Smalley
2005-03-17 14:57                   ` KaiGai Kohei
2005-03-21 10:07                     ` KaiGai Kohei
2005-03-21 15:59                       ` Stephen Smalley
2005-03-23  8:17                         ` Kaigai Kohei
2005-03-23 13:56                           ` Stephen Smalley
2005-04-16  7:31                             ` KaiGai Kohei
2005-04-18 12:25                               ` Stephen Smalley
2005-04-18 16:57                                 ` KaiGai Kohei [this message]
2005-03-24 11:06                           ` Luke Kenneth Casson Leighton
2005-03-24 12:34                             ` Kaigai Kohei
2005-04-06 12:49         ` Russell Coker
2005-04-06 14:50           ` KaiGai Kohei
2005-04-06 15:30             ` Russell Coker
2005-04-06 18:23               ` Jim McCullough
2005-04-07  2:16               ` Kaigai Kohei
2005-04-06 17:55             ` Luke Kenneth Casson Leighton
2005-03-14 16:38 ` Karl MacMillan
2005-03-15 11:47   ` KaiGai Kohei
2005-03-15 14:00     ` Karl MacMillan
2005-03-16  4:35       ` Kaigai Kohei
2005-03-16 10:13         ` Luke Kenneth Casson Leighton
2005-03-16 21:46           ` Karl MacMillan
2005-03-16 21:31         ` Karl MacMillan
2005-03-17 13:05           ` Kaigai Kohei
2005-03-17 19:15             ` Karl MacMillan
2005-03-17 20:07               ` Stephen Smalley
2005-03-17 21:41                 ` Karl MacMillan
2005-03-18 13:13                   ` Stephen Smalley
2005-03-18 13:56                     ` Stephen Smalley
2005-03-18 22:28                     ` Karl MacMillan
2005-03-18 23:03                       ` Luke Kenneth Casson Leighton
2005-03-20 23:20                         ` Karl MacMillan
2005-03-21  0:17                           ` Luke Kenneth Casson Leighton
2005-03-21 13:39                             ` Karl MacMillan
2005-03-22  0:14                               ` Luke Kenneth Casson Leighton
2005-03-22 13:53                                 ` Karl MacMillan
2005-03-24 11:04                                   ` Luke Kenneth Casson Leighton
2005-03-24 12:31                                     ` Kaigai Kohei
2005-03-24 22:19                                       ` Luke Kenneth Casson Leighton
2005-03-24 22:27                                     ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4263E701.6070009@kaigai.gr.jp \
    --to=kaigai@kaigai.gr.jp \
    --cc=kaigai@ak.jp.nec.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.