All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@gmail.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: selinux@tycho.nsa.gov
Subject: Re: learning about policies/transitions
Date: Mon, 15 Nov 2004 10:12:38 -0600	[thread overview]
Message-ID: <46ce702f041115081242f9f8e7@mail.gmail.com> (raw)
In-Reply-To: <1099657575.6373.5.camel@moss-spartans.epoch.ncsc.mil>

Thanks for your help, Stephen.  I've *briefly* looked around at the
inird and /bin/init sources, and can't find an initiial policy that
would be loaded before the root filesystem pivot_root.  I expect to
have more time at the end of this week to figure it out, though.

thanks,
-serge

On Fri, 05 Nov 2004 07:26:15 -0500, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Thu, 2004-11-04 at 21:23, Serge Hallyn wrote:
> > Addendum:  running setfilecon works once.  After each reboot, I must again run
> > setfilecon.before /bin/login will cause the transition to login_d.
> > Again, running
> > /bin/ls -Z /bin/login shows no difference before and after the
> > setifilecon - it is always
> > of type login_et.
> 
> Two scenarios:
> 1) At boot time (e.g. usual policy load by /sbin/init), you are loading
> a policy that does not define login_et, /bin/login inode is brought
> incore and mapped to the unlabeled SID, and you then load a policy that
> does define login_et, but this doesn't automatically fix the incore
> inode SID.
> 2) At boot time, you are loading a policy that does define login_et,
> /bin/login inode is brought incore and mapped to the correct SID, you
> then load a policy that does not define login_et (e.g. Fedora policy),
> invalidating that SID, and you later reload a policy that does define
> login_et, but this doesn't automatically fix the incore inode SID.
> 
> While it would be possible to walk the inode lists upon a policy reload
> and retry mapping of the on-disk xattr for any inode with the unlabeled
> SID, I'm not sure it is worthwhile to do so.
> 
> --
> 
> 
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency
> 
>

--
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:[~2004-11-15 16:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 16:45 learning about policies/transitions Serge Hallyn
2004-11-03 19:29 ` Stephen Smalley
2004-11-04 16:20   ` Serge Hallyn
2004-11-04 17:11     ` Stephen Smalley
2004-11-05  2:23       ` Serge Hallyn
2004-11-05 12:26         ` Stephen Smalley
2004-11-15 16:12           ` Serge Hallyn [this message]
2004-11-15 16:38             ` Stephen Smalley
2004-11-15 17:07               ` Serge Hallyn
2004-11-15 17:28                 ` Stephen Smalley
2004-11-15 18:03                   ` Serge Hallyn
2004-11-23  4:21             ` Russell Coker

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=46ce702f041115081242f9f8e7@mail.gmail.com \
    --to=serge.hallyn@gmail.com \
    --cc=sds@epoch.ncsc.mil \
    --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.