[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: genfs_contexts and /proc/PID files
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2015-03-10 16:34:30
Message-ID: 54FF1D16.4050505 () tycho ! nsa ! gov
[Download RAW message or body]

On 03/09/2015 11:28 AM, Stephen Smalley wrote:
> On 03/07/2015 01:57 PM, Nick Kralevich wrote:
>>
>> I'm trying to figure out how to label a file in /proc/PID with a
>> different SELinux label. In particular, I'm trying to apply an SELinux
>> label to the file /proc/PID/oom_score_adj .
>>
>> I thought this would be easy to do by adding the following line to
>> genfs_contexts:
>>
>> genfscon proc /oom_score_adj u:object_r:MY_NEW_LABEL:s0
>>
>> but this doesn't seem to be working. /proc/PID/oom_score_adj continues
>> to be labeled with the process' label.
>>
>> shell@flounder:/ $ ls -laZ /proc/self/oom_score_adj
>> -rw-r--r-- shell    shell             u:r:shell:s0 oom_score_adj
>>
>> My understanding was that, for /proc, the numeric portion of the path
>> was ignored, and genfscon paths could be relative to the top of the
>> /proc/PID directory. Quoting linux/security/selinux/hooks.c
>>
>>    else {
>>            /* each process gets a /proc/PID/ entry. Strip off the
>>             * PID part to get a valid selinux labeling.
>>             * e.g. /proc/1/net/rpc/nfs -> /net/rpc/nfs */
>>            while (path[1] >= '0' && path[1] <= '9') {
>>                    path[1] = '/';
>>                    path++;
>>            }
>>            rc = security_genfs_sid("proc", path, tclass, sid);
>>    }
>>    free_page((unsigned long)buffer);
>>
>> This logic seems to work for /proc/PID/net, since the files in that
>> directory (but not the directory itself) are labeled with
>> u:object_r:proc_net:s0 . And it seems to work for subdirectories of
>> /proc/PID/net, in particular /proc/PID/net/xt_qtaguid/ctrl in Android is
>> labeled as u:object_r:qtaguid_proc:s0 . However, it doesn't seem to work
>> for files in /proc/PID itself.
>>
>> I've briefly looked through the SELinux code which handles /proc/PID
>> labeling, but it's unclear to me how this code actually works, and how
>> the /proc/PID labels are even created in the first place. The first
>> genfscon proc rule is:
>>
>>   genfscon proc / u:object_r:proc:s0
>>
>> which, if the comment in the code is to be believed, should make all
>> /proc/PID files labeled with "u:object_r:proc:s0". That's obviously not
>> the case...
>>
>> So, my questions are:
>>
>> 1) How do I get a custom label on a file in /proc/PID ?
>>
>> 2) How does the genfscon statements in the policy interact with
>> /proc/PID labeling? Are genfscon statements even consulted at all? And
>> if not, how does /proc/PID/net labeling work?
> 
> genfs_contexts is (or was originally) only used for /proc labeling
> outside of /proc/pid.  /proc/pid inodes are labeled based on the
> associated task by the selinux_task_to_inode() hook function, called by
> security_task_to_inode(), called by proc_pid_make_inode() and
> pid_revalidate().  This happens upon inode creation, before association
> with a dentry/name, so it cannot be name-based presently.  It is always
> just the context of the associated task for all /proc/pid nodes.
> 
> /proc/pid/net was originally /proc/net (i.e. was global rather than
> per-process, prior to introduction of network namespaces) and thus was
> labeled via genfs_contexts.  When they virtualized /proc/net, the
> SELinux logic had to be adjusted to preserve compatibility in labeling
> even though it fell under /proc/pid.  The /proc/pid/net files are not
> assigned the uid/gid of the associated task so it is consistent to label
> them with global SELinux domains/types rather than the task domain.  The
> proc/pid/net inodes are not created via proc_pid_make_inode() and thus
> their isec initialization does not occur at that time, but rather later
> upon association with a dentry, when they have a name.
> 
> We have considered supporting finer granularity on labeling the
> /proc/pid inodes in the past but there hasn't been a compelling case for
> it to date.  It would require a kernel change.

Also, if we were to make such a change, typically we would compute a
context for the /proc/pid inode via security_transition_sid() so that we
can take into account both the associated task context and optionally
the name, since these /proc/pid nodes contain task-private state and
should usually reflect the task security context in some manner.  Then
we could define name-based type transitions for example to specify
finer-grained labeling in policy.  I doubt we would use genfs_contexts,
as that is only name based and cannot take into account the task context.


_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]