Bug 157322 - Cannot erase /halt file
Cannot erase /halt file
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-05-10 12:32 EDT by Ivan Gyurdiev
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-12 01:12:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-05-10 12:32:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3

Description of problem:
audit(1115741783.388:0): avc:  denied  { unlink } for  name=halt dev=dm-0 ino=16 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:root_t tclass=file

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:

Additional info:
Comment 1 Daniel Walsh 2005-05-10 14:05:19 EDT
restorecon /halt 

Any idea how this got created with the wrong context?

Comment 2 Ivan Gyurdiev 2005-05-10 14:28:55 EDT
What creates the halt file?
Comment 3 Daniel Walsh 2005-05-10 17:39:18 EDT
halt command creates this file.

The only way I can see this happening is executing the shutdown from gdm while
in permissive mode.

Comment 4 Ivan Gyurdiev 2005-05-10 18:29:18 EDT
It's entirely possible that I did that - I still turn off selinux all the time,
since it won't let me do various things - most notably I can't attach files
to mozilla, I can't run wine, and I can't run UT2003/4... 

...but why does permissive mode have this effect (w/ regard to halt file?).
Comment 5 Daniel Walsh 2005-05-11 06:06:23 EDT
Because there is a dontaudit rule instead of an allow,  now changing it to 

file_type_auto_trans(xdm_t, root_t, etc_runtime_t, file)

halt and poweroff both attempt to write a flag file to /

halt writes /halt and poweroff writes /poweroff

The /etc/init.d/halt script then has the following command

[ -f /poweroff -o ! -f /halt ] && HALTARGS="$HALTARGS -p"

exec $command $HALTARGS

Which either turns the poweroff on the machine or leaves it running.

At least that is the way I believe it is supposed to run.
Comment 6 Daniel Walsh 2005-05-11 06:17:28 EDT
rc.sysinit tries to delete these files on reboot.

grep poweroff /etc/rc.d/rc.sysinit
rm -f /fastboot /fsckoptions /forcefsck /.autofsck /halt /poweroff &> /dev/null

We have in policy now

file_type_auto_trans({ initrc_t sysadm_t }, root_t, etc_runtime_t, file)

So if the halt command is run by sysadm or via an init script it should get
created with the correct context.  Now if another application can write to the /
partition and executes halt, a file could get created with root_t.  But I don
not know of any.

grep " root_t.*dir.*write" policy.conf
allow bootloader_t root_t:dir { read getattr lock search ioctl add_name
remove_name write };
allow { initrc_t sysadm_t } root_t:dir { read getattr lock search ioctl add_name
remove_name write };
allow quota_t { root_t home_root_t var_t usr_t src_t var_spool_t }:dir { read
getattr lock search ioctl add_name remove_name write };
dontaudit xdm_t root_t:dir { add_name write };

bootloader and quotadb both transition files to bootloader_tmp_t and quota_db_t

I did add file context for /poweroff and a few other files the could be created in /
Comment 7 Ivan Gyurdiev 2005-05-12 01:12:57 EDT
Closing... will reopen if I see it again.

Note You need to log in before you can comment on or make changes to this bug.