pear-shaped behaviour after enough make reloads

pear-shaped behaviour after enough make reloads

[Luke Kenneth Casson Leighton]

i thought i should report what might be quite a serious issue.

the procedure i use for development of policy files is to do
_stacks_ of edits, _stacks_ of make reloads, stacks of
audit2allow -d -v -l > /tmp/foo, analyse the results and put
the appropriate ones into the new policy.

after enough make reloads, the behaviour of my system starts to get
a bit wonky.

for example, i'm doing an executable that is used by hotplug, and
a domain_auto_trans into that new executable's domain...

... yet occasionally i see what looks like evidence of the
domain_auto_trans FAILING.

the GUI users cannot run any programs when this happens.

sometimes if i switch to the GUI (from the console) the screen
goes blank; although i can still use existing ssh connections,
i cannot initiate any new ones.

after a reboot in such circumstances, i find that my system
is pretty much unusable: i have to run a ldconfig to fix a
problem of libraries being not found - things like that.

sometimes i will do a make -C /etc/selinux relabel just to be
sure.

i have to say: this only occurs if i do about ten or twenty
make reloads in a row.

l.

-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.

Re: pear-shaped behaviour after enough make reloads

[Luke Kenneth Casson Leighton]

On Wed, Jul 28, 2004 at 10:12:29PM +0100, Luke Kenneth Casson Leighton wrote:

> i thought i should report what might be quite a serious issue.
> 
> the procedure i use for development of policy files is to do
> _stacks_ of edits, _stacks_ of make reloads, stacks of
> audit2allow -d -v -l > /tmp/foo, analyse the results and put
> the appropriate ones into the new policy.
> 
> after enough make reloads, the behaviour of my system starts to get
> a bit wonky.

> after a reboot in such circumstances, i find that my system
> is pretty much unusable: i have to run a ldconfig to fix a
> problem of libraries being not found - things like that.

 this problem reoccurred just now.
 
 for absolutely no reason that i can think of, whilst staring
 at a random config file with vi, cupsys started to be unable
 to access its config files.

 then i tried to do a ldconfig and got selinux permissions denied
 access to write /etc/ld.so.cache~!

 i could not even do a shutdown - permission was banned to access
 /dev/initctl.

 i had to kill off processes manually one by one, umount the partitions
 manually, poweroff, and i chose to boot with enforcing=0 init 1 in
 order to safely run ldconfig and make relabel.

 i find this all a bit odd, i haven't a clue what's causing it.

 l.



--
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.

Re: pear-shaped behaviour after enough make reloads

[Dale Amon]

On Wed, Jul 28, 2004 at 11:53:22PM +0100, Luke Kenneth Casson Leighton wrote:
>  i had to kill off processes manually one by one, umount the partitions
>  manually, poweroff, and i chose to boot with enforcing=0 init 1 in
>  order to safely run ldconfig and make relabel.
> 
>  i find this all a bit odd, i haven't a clue what's causing it.

Is this particular machine and kernel presently stable 
when running the same kernel and no selinux? I have
seen very strange things happen over the years when
hardware is failing or marginal, power supply voltages
are on the edge... I've seen particular PCI modules
blow the bus out of the water, etc, etc...

Worth checking before you ruin Stephen Smalley's sleep 
and fill it with nightmares of kernel race conditions
and random byte squashers. :-)

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

--
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.

Re: pear-shaped behaviour after enough make reloads

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 11:43:17AM +0100, Dale Amon wrote:
> On Wed, Jul 28, 2004 at 11:53:22PM +0100, Luke Kenneth Casson Leighton wrote:
> >  i had to kill off processes manually one by one, umount the partitions
> >  manually, poweroff, and i chose to boot with enforcing=0 init 1 in
> >  order to safely run ldconfig and make relabel.
> > 
> >  i find this all a bit odd, i haven't a clue what's causing it.
> 
> Is this particular machine and kernel presently stable 
> when running the same kernel and no selinux? 

 as a general rule, yes: i have used it to watch tv and dvds...

 now that you mention it, the hard drive _did_ have a head-crash
 last week when i was doing a 4.3gbyte disk-image...


> I have
> seen very strange things happen over the years when
> hardware is failing or marginal, power supply voltages
> are on the edge... 

 yes, so have i, but having bought eight identical cheap-and-nasty
 machines ($125ea) where one of the PSUs blew so loud it took out its
 internal fuse, the plug fuse, the 4-way-block fuse _and_ the
 mains trip, i didn't want to admit that anything was wrong.

> Worth checking before you ruin Stephen Smalley's sleep 
> and fill it with nightmares of kernel race conditions
> and random byte squashers. :-)
 
 *lol*.

 oh, okay then, i'll try running it without selinux for a while,
 see what happens.

 l.


--
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.

Re: pear-shaped behaviour after enough make reloads

[Luke Kenneth Casson Leighton]

for completeness on list, i should mention that i was modifying
policy files during the make reloads.

stephen mentioned that apparently if inodes are using a SID
that is deleted, no amount of subsequent make reloads will
reattach the SID to that inode.

what happened because of what i was doing to my computer "fits"
with this explanation.

l.


--
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.

Re: pear-shaped behaviour after enough make reloads

[Stephen Smalley]

On Thu, 2004-07-29 at 18:18, Luke Kenneth Casson Leighton wrote:
> for completeness on list, i should mention that i was modifying
> policy files during the make reloads.
> 
> stephen mentioned that apparently if inodes are using a SID
> that is deleted, no amount of subsequent make reloads will
> reattach the SID to that inode.
> 
> what happened because of what i was doing to my computer "fits"
> with this explanation.

Note that the invalidation of security contexts should have been logged
in /var/log/messages upon the policy reload, e.g.
cd /etc/selinux/strict/src/policy
echo "type foo_t, file_type, sysadmfile;" > domains/misc/local.te
touch /tmp/foo
chcon -t foo_t /tmp/foo
rm domains/misc/local.te
make clean load

will yield the following in /var/log/messages or dmesg output for the
final load:
security:  5 users, 7 roles, 1302 types, 2 bools
security:  52 classes, 319241 rules
security:  invalidating context root:object_r:foo_t

At this point, the kernel will treat any incore inodes (or processes, if
this were a domain rather than a file type) that had the type as having
the unlabeled SID, and start denying access.  A ls -Z /tmp/foo will
still show the original context (root:object_r:foo_t), because it is
simply using getxattr to get the extended attribute value from the disk,
and this has not changed, but the kernel no longer has any way of
mapping this value to a meaningful representation in the policy.  But
re-adding the type to the policy won't immediately update the incore
inode's SID; that won't happen until the inode is evicted and
re-instantiated or someone explicitly "relabels" it (but note that chcon
and setfiles likely won't touch it, as they will still see the extended
attribute value as being correct already and refrain from relabeling
it).

-- 
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.

Re: pear-shaped behaviour after enough make reloads

[Luke Kenneth Casson Leighton]

okay, i had the same symptoms happening as i originally described,
and was alert to it this time.

what i had done was install a package with se_apt-get and that package
(autofs) attempted to overwrite /etc/modutils.conf.old (which failed)
and to overwrite /lib/modules/modprobe.conf.old (which also failed).

what i did was to give up, and use apt-get to recover (after deleting
the two .old files) with the intention of manually running
dpkg -L autofs | setfiles -q -s /etc/selinux/file_contexts/file_contexts
afterwards.

... except i didn't get that far, because of errors with ldconfig!

presumably, not only had the installation of autofs done a modules
update, but also it had done a ldconfig - in the wrong security
context.

so when i tried to do ldconfig again, it gave errors about cannot write
/etc/ld.so.cache~

after i had done setfiles /etc/selinux/file_contexts/file_contexts /
(which is a small root partition) i was able to run ldconfig again.

and the computer didn't go pear-shaped, this time.

so, stephen, i owe you an apology for taking up your time on this one.
[but it won't stop me from raising any other issues i find, just in
case]

i _would_ go and upgrade the packages like coreutils etc. like 
russell recommended, which i believe may fix this issue... it's
just that i might also have to upgrade the policy files and i'm
at present a looonng way from the default selinux policy stuff :)

l.

On Fri, Jul 30, 2004 at 08:27:00AM -0400, Stephen Smalley wrote:
> On Thu, 2004-07-29 at 18:18, Luke Kenneth Casson Leighton wrote:
> > for completeness on list, i should mention that i was modifying
> > policy files during the make reloads.
> > 
> > stephen mentioned that apparently if inodes are using a SID
> > that is deleted, no amount of subsequent make reloads will
> > reattach the SID to that inode.
> > 
> > what happened because of what i was doing to my computer "fits"
> > with this explanation.
> 
> Note that the invalidation of security contexts should have been logged
> in /var/log/messages upon the policy reload, e.g.
> cd /etc/selinux/strict/src/policy
> echo "type foo_t, file_type, sysadmfile;" > domains/misc/local.te
> touch /tmp/foo
> chcon -t foo_t /tmp/foo
> rm domains/misc/local.te
> make clean load
> 
> will yield the following in /var/log/messages or dmesg output for the
> final load:
> security:  5 users, 7 roles, 1302 types, 2 bools
> security:  52 classes, 319241 rules
> security:  invalidating context root:object_r:foo_t
> 
> At this point, the kernel will treat any incore inodes (or processes, if
> this were a domain rather than a file type) that had the type as having
> the unlabeled SID, and start denying access.  A ls -Z /tmp/foo will
> still show the original context (root:object_r:foo_t), because it is
> simply using getxattr to get the extended attribute value from the disk,
> and this has not changed, but the kernel no longer has any way of
> mapping this value to a meaningful representation in the policy.  But
> re-adding the type to the policy won't immediately update the incore
> inode's SID; that won't happen until the inode is evicted and
> re-instantiated or someone explicitly "relabels" it (but note that chcon
> and setfiles likely won't touch it, as they will still see the extended
> attribute value as being correct already and refrain from relabeling
> it).
> 
> -- 
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency
> 

-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.