selinux and AFS

selinux and AFS

[Forrest Whitcher]

Stephen et al.

I imagine you've had enough 'progress' reports from me, however
I *think* I have figured out the cause of the failure in getting
openAFS to run under the selinux kernel (2.2.19).

Diagnostics on attempting mount were:

>From afsd:
--afsd: Mounting the AFS root on '/afs', flags: 0.
--afsd: Can't mount AFS on /afs(22)

>From the kernel:
--security_compute_av:  unrecognized SID 0
--psid_release:  uninitialized super block

I traced the return call error (EINVAL) to two places. 

First in super.c lines 973, 981 - psid_release when afs attempts 
the mount.

Second in security/services.c at lines 727, 278 - security_compute_av.

I then modified the former to never return an error code, thus 
allowing the mount to proceed. At this point, every attempt to
touch an object at or below the /afs root results in a repetition
of the last diagnostic

--security_compute_av:  unrecognized SID 0

(in these instances it is failing on the 'tsid' lookup- services.c l 278;
in the mount attempt it is the ssid lookup - services.c l 272)

obviously I can  'echo /*' and see that the afs dir is there, however
the above error is returned by any attempt to actually read data
from the filesystem (ls || stat || ...)

Although I have not had time to further trace into the kernel 
sources (spent some time digging, but other things came up)..

I believe I have a good guess about what's causing the problem.

AFS identifies the inode of the 'AFS' type filesystem (mounted
on /afs) as '0'. Is it likely that your routines are seeing the
'0' inode number and giving up / returning the errors to the
callers?

Thanks for any comments, I will have time later in the month to 
delve into this further, meantime, I'd hope to understand the 
hangup prior to heading down to DC next week for the security 
symp.


-- 
Forrest Whitcher    Principal      FW Systems 
617.254.3506                       fw@fwsystems.com                 
fw@world.std.com                   6174803245@mobile.att.net
Information systems consulting     http://www.fwsystems.com

--
You have received this message because you are subscribed to the selinux 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: selinux and AFS

[Stephen Smalley]

On Wed, 8 Aug 2001, Forrest Whitcher wrote:

> >From the kernel:
> --security_compute_av:  unrecognized SID 0
> --psid_release:  uninitialized super block
> 
> First in super.c lines 973, 981 - psid_release when afs attempts 
> the mount.

Ok, so this suggests that the AVC_HAS_PERM call on line 971 
of super.c passed a 0 for sb->s_sid.  So how was the super_block
structure allocated?  If it was allocated by get_empty_super
in fs/super.c, then it should have the unlabeled SID
(SECINITSID_UNLABELED), which is not 0.  So I don't know
why this would be 0.

> I then modified the former to never return an error code, thus 
> allowing the mount to proceed. At this point, every attempt to
> touch an object at or below the /afs root results in a repetition
> of the last diagnostic
> 
> --security_compute_av:  unrecognized SID 0

So, how are the inode structures allocated for AFS?  If they
use get_empty_inode or get_new_inode, then clean_inode 
initializes the inode to the unlabeled SID. Again, this
shouldn't be zero.

> in the mount attempt it is the ssid lookup - services.c l 272)

That's surprising.  The 'ssid' for the mount check would be
current->sid - the SID of the current process.  That is
set for the initial task, inherited by fork, and potentially
changed on execve in accordance with the policy.  So I don't
know how you are ending up with a 0 SID here.

> AFS identifies the inode of the 'AFS' type filesystem (mounted
> on /afs) as '0'. Is it likely that your routines are seeing the
> '0' inode number and giving up / returning the errors to the
> callers?

Shouldn't matter.  The filesystem and inodes should show up
with the unlabeled SID, and hence system_u:object_r:unlabeled_t.

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




--
You have received this message because you are subscribed to the selinux 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.