Bug 157322 - Cannot erase /halt file
Summary: Cannot erase /halt file
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-10 16:32 UTC by Ivan Gyurdiev
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-12 05:12:57 UTC
Type: ---


Attachments (Terms of Use)

Description Ivan Gyurdiev 2005-05-10 16:32:43 UTC
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):
selinux-policy-strict-1.23.15-1

How reproducible:
Didn't try

Steps to Reproduce:


Additional info:

Comment 1 Daniel Walsh 2005-05-10 18:05:19 UTC
restorecon /halt 

Any idea how this got created with the wrong context?

Dan

Comment 2 Ivan Gyurdiev 2005-05-10 18:28:55 UTC
What creates the halt file?

Comment 3 Daniel Walsh 2005-05-10 21:39:18 UTC
halt command creates this file.

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

Dan

Comment 4 Ivan Gyurdiev 2005-05-10 22:29:18 UTC
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 10:06:23 UTC
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 10:17:28 UTC
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
respectively

I did add file context for /poweroff and a few other files the could be created in /

Comment 7 Ivan Gyurdiev 2005-05-12 05:12:57 UTC
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.