mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: "Christian Göttsche" <cgzones@googlemail.com>, selinux@vger.kernel.org
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
	Eric Paris <eparis@parisplace.org>,
	Xiu Jianfeng <xiujianfeng@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selinux: deprecated fs ocon
Date: Thu, 18 May 2023 13:56:25 -0400	[thread overview]
Message-ID: <6301fdfd0927df2b2fd7a4f2b384e477.paul@paul-moore.com> (raw)
In-Reply-To: <20230511123213.722912-1-cgzones@googlemail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

On May 11, 2023 =?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgzones@googlemail.com> wrote:
> 
> The object context type `fs`, not to be confused with the well used
> object context type `fscon`, was introduced in the initial git commit
> 1da177e4c3f4 ("Linux-2.6.12-rc2") but never actually used since.
> 
> The paper "A Security Policy Configuration for the Security-Enhanced
> Linux" [1] mentions it under `7.2 File System Contexts` but also states:
> 
>     Currently, this configuration is unused.
> 
> The policy statement defining such object contexts is `fscon`, e.g.:
> 
>     fscon 2 3 gen_context(system_u:object_r:conA_t,s0) gen_context(system_u:object_r:conB_t,s0)
> 
> It is not documented at selinuxproject.org or in the SELinux notebook
> and not supported by the Reference Policy buildsystem - the statement is
> not properly sorted - and thus not used in the Reference or Fedora
> Policy.
> 
> Print a warning message at policy load for each such object context:
> 
>     SELinux:  void and deprecated fs ocon 02:03
> 
> This topic was initially highlighted by Nicolas Iooss [2].
> 
> [1]: https://media.defense.gov/2021/Jul/29/2002815735/-1/-1/0/SELINUX-SECURITY-POLICY-CONFIGURATION-REPORT.PDF
> [2]: https://lore.kernel.org/selinux/CAJfZ7=mP2eJaq2BfO3y0VnwUJaY2cS2p=HZMN71z1pKjzaT0Eg@mail.gmail.com/
> 
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
>  security/selinux/ss/policydb.c | 4 ++++
>  security/selinux/ss/policydb.h | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)

Thanks, this is a nice catch, although some minor suggestions below ...

> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
> index 97c0074f9312..31b08b34c722 100644
> --- a/security/selinux/ss/policydb.c
> +++ b/security/selinux/ss/policydb.c
> @@ -2257,6 +2257,10 @@ static int ocontext_read(struct policydb *p, const struct policydb_compat_info *
>  				if (rc)
>  					goto out;
>  
> +				if (i == OCON_FS)
> +					pr_warn("SELinux:  void and deprecated fs ocon %s\n",
> +						c->u.name);

Instead of having to check if 'i == OCON_FS', why not simply put the
pr_warn() call up in the OCON_FS case block on line ~2249 and let it
continue to fallthrough to the OCON_NETIF block?

>  				rc = context_read_and_validate(&c->context[0], p, fp);
>  				if (rc)
>  					goto out;
> diff --git a/security/selinux/ss/policydb.h b/security/selinux/ss/policydb.h
> index ffc4e7bad205..39cd6222e1a8 100644
> --- a/security/selinux/ss/policydb.h
> +++ b/security/selinux/ss/policydb.h
> @@ -225,7 +225,7 @@ struct genfs {
>  
>  /* object context array indices */
>  #define OCON_ISID	0 /* initial SIDs */
> -#define OCON_FS		1 /* unlabeled file systems */
> +#define OCON_FS		1 /* unlabeled file systems (deprecated in 6.5) */

Since you are likely re-spinning this (see above), I would just leave
it as "(deprecated)"; those that want to know where it was deprecated
can always check the git log/tags.

>  #define OCON_PORT	2 /* TCP and UDP port numbers */
>  #define OCON_NETIF	3 /* network interfaces */
>  #define OCON_NODE	4 /* nodes */
> -- 
> 2.40.1

--
paul-moore.com

  reply	other threads:[~2023-05-18 17:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 12:32 Christian Göttsche
2023-05-18 17:56 ` Paul Moore [this message]
2023-05-18 20:18   ` Paul Moore
2023-05-23 18:25     ` Christian Göttsche
2023-05-23 19:38       ` Paul Moore

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=6301fdfd0927df2b2fd7a4f2b384e477.paul@paul-moore.com \
    --to=paul@paul-moore.com \
    --cc=cgzones@googlemail.com \
    --cc=eparis@parisplace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=xiujianfeng@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®