/proc woes

/proc woes

[Tom]

Forget my last posting. I noticed a few seconds after pressing send
that of course all that is no good because /proc is not a supported
filesystem.

So instead of having a patch, I have a question: My /proc is file_t:

dr-xr-xr-x  root     root     system_u:object_r:file_t         proc

Doing a chcon manually fails:

# chcon system_u:object_r:proc_t /proc
chcon: /proc: Permission denied


So, what went wrong and what can I do to fix it?


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: /proc woes

[Stephen Smalley]

On Tue, 8 Oct 2002, Tom wrote:

> So instead of having a patch, I have a question: My /proc is file_t:
>
> dr-xr-xr-x  root     root     system_u:object_r:file_t         proc

This implies that your /proc is an empty mountpoint and is thus unused.

> Doing a chcon manually fails:
>
> # chcon system_u:object_r:proc_t /proc
> chcon: /proc: Permission denied

Why do you need to assign a different type to this empty mountpoint?  It
doesn't need to be accessed by anything.  Are you just trying to avoid
audit messages about attempts to access it?

The permission denial is due to the filesystem associate permission check
between the file type and the filesystem type.  proc_t isn't authorized to
be associated with an ordinary filesystem type like fs_t.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
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: /proc woes

[Tom]

On Tue, Oct 08, 2002 at 10:40:30AM -0400, Stephen Smalley wrote:
> > So instead of having a patch, I have a question: My /proc is file_t:
> >
> > dr-xr-xr-x  root     root     system_u:object_r:file_t         proc
> 
> This implies that your /proc is an empty mountpoint and is thus unused.

No, it was populated and in use. (mount showed it mounted, and umount
failed with busy).


Rebooting the machine fixed it, so this may have happened during either
make relabel or make load (I installed a new policy today), though it's
still a mystery to me how and I'm one of the people who believe that a
reboot shouldn't be a valid solution. :)


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: /proc woes

[Russell Coker]

On Tue, 8 Oct 2002 17:11, Tom wrote:
> On Tue, Oct 08, 2002 at 10:40:30AM -0400, Stephen Smalley wrote:
> > > So instead of having a patch, I have a question: My /proc is file_t:
> > >
> > > dr-xr-xr-x  root     root     system_u:object_r:file_t         proc
> >
> > This implies that your /proc is an empty mountpoint and is thus unused.
>
> No, it was populated and in use. (mount showed it mounted, and umount
> failed with busy).
>
>
> Rebooting the machine fixed it, so this may have happened during either
> make relabel or make load (I installed a new policy today), though it's
> still a mystery to me how and I'm one of the people who believe that a
> reboot shouldn't be a valid solution. :)

If you do the following:
echo /proc | setfiles -s -v /etc/selinux/file_contexts/file_contexts
Then it will be relabelled to file_t.

The Debian package base-files "owns" /proc and therefore it will be relabelled 
in the fashion shown above if you upgrade your base-files package.

The solution to this is to add an entry to file_contexts for /proc.

In my tree I added the following as line 147 of types.fc to avoid this 
happening in future.  Steve, please include something equivalent in the CVS, 
although it's only used by Debian now, the same issue will probably be faced 
by RPM distributions when they support SE Linux (and in any case it does no 
harm).
/proc(/.*)?                     <<none>>

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

Re: /proc woes

[Stephen Smalley]

On Tue, 8 Oct 2002, Tom wrote:

> Rebooting the machine fixed it, so this may have happened during either
> make relabel or make load (I installed a new policy today), though it's
> still a mystery to me how and I'm one of the people who believe that a
> reboot shouldn't be a valid solution. :)

I can't see any reason why a 'make relabel' or a 'make load' would yield
this behavior.  'make relabel' only runs setfiles on mounted ext[23] or
reiserfs filesystems to create or update the persistent label mappings.
'make load' doesn't relabel anything, although it might invalidate
security contexts if you removed types (like proc_t), leaving existing
objects in unlabeled_t (but not file_t).

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
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: /proc woes

[Tom]

On Tue, Oct 08, 2002 at 02:43:12PM -0400, Stephen Smalley wrote:
> > Rebooting the machine fixed it, so this may have happened during either
> > make relabel or make load (I installed a new policy today), though it's
> > still a mystery to me how and I'm one of the people who believe that a
> > reboot shouldn't be a valid solution. :)
> 
> I can't see any reason why a 'make relabel' or a 'make load' would yield
> this behavior.  'make relabel' only runs setfiles on mounted ext[23] or
> reiserfs filesystems to create or update the persistent label mappings.
> 'make load' doesn't relabel anything, although it might invalidate
> security contexts if you removed types (like proc_t), leaving existing
> objects in unlabeled_t (but not file_t).

Well, I *am* somewhat puzzled myself, but I've seen it happen. I will
experiment a little tomorrow afternoon to see if I can recreate it
(probably by replaying the bash history) and find out what caused this.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: /proc woes

[Tom]

On Tue, Oct 08, 2002 at 07:13:17PM +0200, Russell Coker wrote:
> If you do the following:
> echo /proc | setfiles -s -v /etc/selinux/file_contexts/file_contexts
> Then it will be relabelled to file_t.
> 
> The Debian package base-files "owns" /proc and therefore it will be relabelled 
> in the fashion shown above if you upgrade your base-files package.

That sounds like it's what happened, since I did indeed do a major
update that most likely included base-files.


-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

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