Sepcut Relabel problem

Sepcut Relabel problem

[Mark Shakespeare]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

Trying to relabel file system from within Sepcut ( most current version )

getting a weird error....


couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory
couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory
     while executing
"::open $tmpfilename "RDONLY""
     (procedure "Sepct_Test::test_Policy" line 87)
     invoked from within
"Sepct_Test::test_Policy relabel"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .mainframe.frame.nb.fSepct_Test.rightf.relabel"
     (command bound to event)


Sepcut hangs....then no other X-based apps can run. A reboot clears things.

Any ideas?

I'am using the most recent versions of Policy.


								Mark


-- 
******************************************
* Mark Shakespeare			 *
* Engineering Computer Operations Team   *
* Lawrence Livermore National Laboratory *
* 7000 East Ave		L-130            *
* Livermore,Ca 94550			 *
* 925-423-9922	      mshakes@llnl.gov   *
******************************************

[-- Attachment #2: Type: text/html, Size: 2996 bytes --]

Re: Sepcut Relabel problem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Tue, 06 Apr 2004 16:31:12 PDT, Mark Shakespeare <mshakes@llnl.gov>  said:
> --============_-1130828223==_ma============
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> Trying to relabel file system from within Sepcut ( most current version )
> 
> getting a weird error....
> 
> 
> couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory
> couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory

> Sepcut hangs....then no other X-based apps can run. A reboot clears things.
> 
> Any ideas?

Seen in /etc/security/selinux/src/policy/Makefile:

relabel:  $(FC) $(SETFILES)
        @echo "Cleaning out /tmp"
        -rm -rf /tmp/.??* /tmp/*

which is where your /tmp/sepcut-* and /tmp/.X11-unix/ went (the first
explaining your sepcut error, the second explaining your X11 problem).

I'll let somebody else address the question of whether that 'rm' command
is over-zealous, as I'm not sure what it's trying to do.  If it's trying to
make sure there's no symlink attacks, it's going about it wrongly, as all
that does is close down the race conditions a bit.

Most likely, what it *should* be doing is a mkdir and working inside that
directory for temp files.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Sepcut Relabel problem

[David Caplan]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 06 Apr 2004 16:31:12 PDT, Mark Shakespeare <mshakes@llnl.gov>  said:
> 
>>--============_-1130828223==_ma============
>>Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>>
>>Trying to relabel file system from within Sepcut ( most current version )
>>
>>getting a weird error....
>>
>>
>>couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory
>>couldn't open "/tmp/sepcut-zrqWs8Ew": no such file or directory
> 
> 
>>Sepcut hangs....then no other X-based apps can run. A reboot clears things.
>>
>>Any ideas?
> 
> 
> Seen in /etc/security/selinux/src/policy/Makefile:
> 
> relabel:  $(FC) $(SETFILES)
>         @echo "Cleaning out /tmp"
>         -rm -rf /tmp/.??* /tmp/*
> 
> which is where your /tmp/sepcut-* and /tmp/.X11-unix/ went (the first
> explaining your sepcut error, the second explaining your X11 problem).
> 
> I'll let somebody else address the question of whether that 'rm' command
> is over-zealous, as I'm not sure what it's trying to do.  If it's trying to
> make sure there's no symlink attacks, it's going about it wrongly, as all
> that does is close down the race conditions a bit.
> 
> Most likely, what it *should* be doing is a mkdir and working inside that
> directory for temp files.

The "rm" line appears to have been added relatively recently to the 
relabel target.  My guess is that the rationale was that many of the 
files in /tmp were no longer labeled correctly after a relabel because 
most of them would have been created via a file transition rule (and 
thus a relabel would change them all to incorrect/default labels, most 
likely denying access to the files anyway if the system were in 
enforcing mode).

David


--
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: Sepcut Relabel problem

[Russell Coker]

On Thu, 8 Apr 2004 02:17, David Caplan <dac@tresys.com> wrote:
> The "rm" line appears to have been added relatively recently to the
> relabel target.  My guess is that the rationale was that many of the
> files in /tmp were no longer labeled correctly after a relabel because
> most of them would have been created via a file transition rule (and
> thus a relabel would change them all to incorrect/default labels, most
> likely denying access to the files anyway if the system were in
> enforcing mode).

Your guess is correct.  Correctly labelling all the files in /tmp is virtually 
impossible.  Leaving existing entries in /tmp as file_t does not work as many 
programs use fixed file names (of course that's usually a bad idea, but 
that's another discussion) and won't work if the file names exist and can't 
be unlinked.

There are two solutions to this problem, one is to have your system clean /tmp 
on reboot (as is done in Debian).  The other is to have a relabel clean 
out /tmp.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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