On Wed, 16 May 2007 22:54:00 +1000, Russell Coker <[EMAIL PROTECTED]> said:
> I have attached a patch that I'm using in my work on getting a strict
> unstable system to work.
Applied the changes, and uploaded a new refpolicy package.
> I believe that cron should be allowed to set limits, although this
> could possibly be done in a boolean.
I have not yet made this change. I have discovered additional
issues with cron;
,----
| #============= initrc_t ==============
| # src="initrc_t" tgt="crond_t" class="fifo_file", perms="{ read ioctl }"
| # comm="sysklogd" exe="" path=""
| allow initrc_t crond_t:fifo_file { read ioctl };
| # src="initrc_t" tgt="system_crond_t" class="fd", perms="use"
| # comm="sysklogd" exe="" path=""
| allow initrc_t system_crond_t:fd use;
| # src="initrc_t" tgt="system_crond_t" class="fifo_file", perms="write"
| # comm="sysklogd" exe="" path=""
| allow initrc_t system_crond_t:fifo_file write;
| #============= system_crond_t ==============
| # src="system_crond_t" tgt="apt_var_lib_t" class="file", perms="read"
| # comm="cp" exe="" path=""
| allow system_crond_t apt_var_lib_t:file read;
| # src="system_crond_t" tgt="var_t" class="dir", perms="{ write add_name }"
| # comm="cp" exe="" path=""
| allow system_crond_t var_t:dir { write add_name };
| # src="system_crond_t" tgt="var_t" class="file", perms="{ write create
setattr }"
| # comm="cp" exe="" path=""
| allow system_crond_t var_t:file { write create setattr };
`----
I want to look into these a bit more before making the changes
in refpolicy.
> fsadm_t asks for security_t because it's linked against libblkid.so.1
> which is linked against libdevmapper.so.1.02.1 which is linked against
> libselinux.so.1. The load phase of libselinux.so.1 will access things
> under /selinux. I posted to the SE Linux list about this issue last
> night but haven't got any replies yet. I suggest no policy changes in
> this regard until we get things sorted out correctly (don't want to
> hide problems).
> The mount_t security_t issue is the same as for fsadm_t.
> I think it's appropriate for semanage_t to access security_t even
> though it might not need it at the moment (it's an area that's
> evolving and semanage_t can break things anyway).
> Above is the code from unix_chkpwd.c that uses libselinux and
> therefore wants to access security_t. I think it would be a bad idea
> to prevent such access.
I have not made these changes yet, but it seems like it should
do no harm to permit these.
> The mountnfs is one I think I haven't solved yet.
> I don't know why unix_chkpwd is looking under /var/run, does it fail
> to work when that access is prevented?
Not in the cases I have observed.
However, when cretaing the refpolicy package itself, I can
across this little denial while linking:
,----
| #============= user_t ==============
| # src="user_t" tgt="shlib_t" class="file", perms="ioctl"
| # comm="ld" exe="" path=""
| allow user_t shlib_t:file ioctl;
`----
Shouldn't that be allowed?
manoj
--
* JHM wonders what Joey did to earn "I'd just like to say, for the
record, that Joey rules." -- Seen on #Debian
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
