Strange staff role problems...

Strange staff role problems...

[Ivan Gyurdiev]

What does this mean, exactly, and what can cause it?

Feb 22 22:19:15 cobra kernel: inode_doinit_with_dentry:
context_to_sid([username]:object_r:staff_home_dir_t) returned 22 for
dev=dm-2 ino=324481

Feb 22 22:20:44 cobra kernel: inode_doinit_with_dentry:
context_to_sid([username]:object_r:staff_home_t) returned 22 for
dev=dm-2 ino=324482

Something's broken on my machine. I had to reboot,
and then gdm said my home directory is missing (which it isn't - 
apparently it sees unlabeled context, which doesn't make any sense 
either, because ls -Z shows staff_home_dir_t).

Then I enable permissive mode, start X, and it creates unlabeled_t 
Xauthority file. Restorecon properly restores that to staff_home_t.

What could be the problem?
I have all the right users and roles, I think
in /etc/selinux/strict/users/local.users

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Strange staff role problems...

[Stephen Smalley]

On Tue, 2005-02-22 at 23:07 -0500, Ivan Gyurdiev wrote:
> What does this mean, exactly, and what can cause it?
> 
> Feb 22 22:19:15 cobra kernel: inode_doinit_with_dentry:
> context_to_sid([username]:object_r:staff_home_dir_t) returned 22 for
> dev=dm-2 ino=324481

22 == EINVAL.  This means that the security context was invalid with
respect to the current policy, which typically means that:
- one of the components (user, role, type) is no longer defined in the
policy, or
- the combination of the components is illegal in the policy

Given what you show above, I'd assume that the user is no longer defined
in the policy.

> Something's broken on my machine. I had to reboot,
> and then gdm said my home directory is missing (which it isn't - 
> apparently it sees unlabeled context, which doesn't make any sense 
> either, because ls -Z shows staff_home_dir_t).

ls -Z (or other applications) will display the on-disk extended
attribute value, regardless of whether it is valid or not, as the xattr
API queries the filesystem code, not the security module (other than to
check permissions for accessing the xattr).  Hence, SELinux may
internally be treating it as unlabeled due to an invalid context.

> Then I enable permissive mode, start X, and it creates unlabeled_t 
> Xauthority file. Restorecon properly restores that to staff_home_t.

If the home directory is being treated internally as unlabeled, then any
files created in it will by default also inherit that label.

> What could be the problem?
> I have all the right users and roles, I think
> in /etc/selinux/strict/users/local.users

We only recently introduced support for actually using local.users, by
adding sepol_genusers(3) to libsepol and modifying load_policy(1) to
call it prior to loading the policy into the kernel.  At the same time,
we changed the policy Makefile to no longer pull in local.users upon a
policy build because it is now being dynamically added to the in-memory
binary policy image by load_policy(1).  AFAIK, Dan is still working on
the patch to /sbin/init to likewise call sepol_genusers(3) prior to
loading the policy into the kernel.  Until that change is made, you'll
lose any user definitions in local.users upon a reboot until you run
load_policy, because /sbin/init won't dynamically pull in those entries.
In the short term, you can either restore the inclusion of local.users
into your policy build or separately run genpolusers(1) to rebuild the
binary policy file with local.users included.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
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: Strange staff role problems...

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Tue, 2005-02-22 at 23:07 -0500, Ivan Gyurdiev wrote:
>  
>
>>What does this mean, exactly, and what can cause it?
>>
>>Feb 22 22:19:15 cobra kernel: inode_doinit_with_dentry:
>>context_to_sid([username]:object_r:staff_home_dir_t) returned 22 for
>>dev=dm-2 ino=324481
>>    
>>
>
>22 == EINVAL.  This means that the security context was invalid with
>respect to the current policy, which typically means that:
>- one of the components (user, role, type) is no longer defined in the
>policy, or
>- the combination of the components is illegal in the policy
>
>Given what you show above, I'd assume that the user is no longer defined
>in the policy.
>
>  
>
>>Something's broken on my machine. I had to reboot,
>>and then gdm said my home directory is missing (which it isn't - 
>>apparently it sees unlabeled context, which doesn't make any sense 
>>either, because ls -Z shows staff_home_dir_t).
>>    
>>
>
>ls -Z (or other applications) will display the on-disk extended
>attribute value, regardless of whether it is valid or not, as the xattr
>API queries the filesystem code, not the security module (other than to
>check permissions for accessing the xattr).  Hence, SELinux may
>internally be treating it as unlabeled due to an invalid context.
>
>  
>
>>Then I enable permissive mode, start X, and it creates unlabeled_t 
>>Xauthority file. Restorecon properly restores that to staff_home_t.
>>    
>>
>
>If the home directory is being treated internally as unlabeled, then any
>files created in it will by default also inherit that label.
>
>  
>
>>What could be the problem?
>>I have all the right users and roles, I think
>>in /etc/selinux/strict/users/local.users
>>    
>>
>
>We only recently introduced support for actually using local.users, by
>adding sepol_genusers(3) to libsepol and modifying load_policy(1) to
>call it prior to loading the policy into the kernel.  At the same time,
>we changed the policy Makefile to no longer pull in local.users upon a
>policy build because it is now being dynamically added to the in-memory
>binary policy image by load_policy(1).  AFAIK, Dan is still working on
>the patch to /sbin/init to likewise call sepol_genusers(3) prior to
>loading the policy into the kernel.  Until that change is made, you'll
>lose any user definitions in local.users upon a reboot until you run
>load_policy, because /sbin/init won't dynamically pull in those entries.
>In the short term, you can either restore the inclusion of local.users
>into your policy build or separately run genpolusers(1) to rebuild the
>binary policy file with local.users included.
>
>  
>
Should be in Rawhide tonight.  I have put it out on my people page
ftp://people.redhat.com/dwalsh/SELinux/Fedora

I have attached the patch.

Dan

[-- Attachment #2: sysvinit-2.85-selgenusers.patch --]
[-- Type: text/plain, Size: 1489 bytes --]

--- sysvinit-2.85/src/init.c.selgenusers	2005-02-17 19:03:08.000000000 -0500
+++ sysvinit-2.85/src/init.c	2005-02-17 19:03:49.000000000 -0500
@@ -199,9 +199,10 @@
 static int load_policy(int *enforce) 
 {
 	int fd=-1,ret=-1;
+	unsigned data_size;
 	int rc=0, orig_enforce;
 	struct stat sb;
-	void *map;
+	void *map, *data;
 	char policy_file[PATH_MAX];
 	int policy_version=0;
 	FILE *cfg;
@@ -306,8 +307,21 @@
 	}
 
 
+	ret = sepol_genusers(map, sb.st_size, selinux_users_path(), &data, &data_size);
+	if (ret < 0) {
+		if (errno == ENOENT || errno == EINVAL) {
+			/* No booleans file or stale booleans in the file; non-fatal. */
+			log(L_VB,"Warning!  Error while user configuration from %s:  %s\n", selinux_users_path(), strerror(errno));
+			data=map;
+			data_size=sb.st_size;
+		} else {
+			log(L_VB, "Error while setting user configuration from %s:  %s\n", selinux_users_path(), strerror(errno));
+			goto UMOUNT;
+		}
+	}
+
 	/* Set booleans based on a booleans configuration file. */
-	ret = sepol_genbools(map, sb.st_size, selinux_booleans_path());
+	ret = sepol_genbools(data, data_size, selinux_booleans_path());
 	if (ret < 0) {
 		if (errno == ENOENT || errno == EINVAL) {
 			/* No booleans file or stale booleans in the file; non-fatal. */
@@ -320,7 +334,7 @@
 		}
 	}
 	log(L_VB, "Loading security policy\n");
-	ret=security_load_policy(map, sb.st_size);
+	ret=security_load_policy(data, data_size);
 	if (ret < 0) {
 		log(L_VB, "security_load_policy failed\n");
 	}

Re: Strange staff role problems...

[Stephen Smalley]

On Wed, 2005-02-23 at 11:29 -0500, Daniel J Walsh wrote:
> Should be in Rawhide tonight.  I have put it out on my people page
> ftp://people.redhat.com/dwalsh/SELinux/Fedora
> 
> I have attached the patch.

1) data_size should be size_t (same as fix by Ulrich to load_policy).

2) Error message looks like it is missing a verb (while <blank> user
configuration), and the comment is cut-and-paste from the booleans.

3) Do you really want it to fail completely if sepol_genusers() returns
an error other than ENOENT or EINVAL (e.g. ENOMEM is possible, EACCES is
possible if it lacks permission to read the file, ...)?  Likely should
just always proceed with the original binary policy if there is any
error from sepol_genusers().  That will let the system come up with
system_u, user_u, and root for basic recovery.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
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: Strange staff role problems...

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Wed, 2005-02-23 at 11:29 -0500, Daniel J Walsh wrote:
>  
>
>>Should be in Rawhide tonight.  I have put it out on my people page
>>ftp://people.redhat.com/dwalsh/SELinux/Fedora
>>
>>I have attached the patch.
>>    
>>
>
>1) data_size should be size_t (same as fix by Ulrich to load_policy).
>
>2) Error message looks like it is missing a verb (while <blank> user
>configuration), and the comment is cut-and-paste from the booleans.
>
>3) Do you really want it to fail completely if sepol_genusers() returns
>an error other than ENOENT or EINVAL (e.g. ENOMEM is possible, EACCES is
>possible if it lacks permission to read the file, ...)?  Likely should
>just always proceed with the original binary policy if there is any
>error from sepol_genusers().  That will let the system come up with
>system_u, user_u, and root for basic recovery.
>
>  
>
Ok try again.

[-- Attachment #2: sysvinit-2.85-selgenusers.patch --]
[-- Type: text/plain, Size: 1329 bytes --]

--- sysvinit-2.85/src/init.c.selgenusers	2005-02-23 11:47:17.000000000 -0500
+++ sysvinit-2.85/src/init.c	2005-02-23 11:51:07.000000000 -0500
@@ -199,9 +199,10 @@
 static int load_policy(int *enforce) 
 {
 	int fd=-1,ret=-1;
+	size_t data_size;
 	int rc=0, orig_enforce;
 	struct stat sb;
-	void *map;
+	void *map, *data;
 	char policy_file[PATH_MAX];
 	int policy_version=0;
 	FILE *cfg;
@@ -306,8 +307,16 @@
 	}
 
 
+	/* Set SELinux users based on a local.users configuration file. */
+	ret = sepol_genusers(map, sb.st_size, selinux_users_path(), &data, &data_size);
+	if (ret < 0) {
+		log(L_VB,"Warning!  Error while reading user configuration from %s/{local.users,system.users}:  %s\n", selinux_users_path(), strerror(errno));
+		data=map;
+		data_size=sb.st_size;
+	}
+
 	/* Set booleans based on a booleans configuration file. */
-	ret = sepol_genbools(map, sb.st_size, selinux_booleans_path());
+	ret = sepol_genbools(data, data_size, selinux_booleans_path());
 	if (ret < 0) {
 		if (errno == ENOENT || errno == EINVAL) {
 			/* No booleans file or stale booleans in the file; non-fatal. */
@@ -320,7 +329,7 @@
 		}
 	}
 	log(L_VB, "Loading security policy\n");
-	ret=security_load_policy(map, sb.st_size);
+	ret=security_load_policy(data, data_size);
 	if (ret < 0) {
 		log(L_VB, "security_load_policy failed\n");
 	}

Re: Strange staff role problems...

[Stephen Smalley]

On Wed, 2005-02-23 at 11:53 -0500, Daniel J Walsh wrote:
> Ok try again.

Looks good.  Of course, you'll need to update the spec file if you
haven't already to depend on versions of libselinux and libsepol that
include the necessary support (libselinux >= 1.21.10, libsepol >=
1.3.4).

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
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: Strange staff role problems...

[Ivan Gyurdiev]

On Wed, 2005-02-23 at 12:12 -0500, Stephen Smalley wrote:
>On Wed, 2005-02-23 at 11:53 -0500, Daniel J Walsh wrote:
>> Ok try again.
>
>Looks good.  Of course, you'll need to update the spec file if you
>haven't already to depend on versions of libselinux and libsepol that
>include the necessary support (libselinux >= 1.21.10, libsepol >=
>1.3.4).

In case you think this is important...
load_policy's not working for me re: fixing this issue.
It says policy loaded, shows 10 users (as opposed to 4 after init).
Then I restorecon the entire home folder, it properly restores
unlabeled_t files to staff_home_t, and ...

I try to login, and I get denials that my home folder is unlabeled_t.

I should note that while restorecon changes newly created unlabeled_t
files to staff_home_t, it does nothing about my home folder (because
it already says staff_home_dir_t on disk. Yet it says unlabeled_t
on attempted access even after users are loaded.

P.S. Why are there no SRPMS on dwalsh's repository..
I found some, but they're not the right ones against rawhide, and I
don't see sepol there.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Strange staff role problems...

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>On Wed, 2005-02-23 at 12:12 -0500, Stephen Smalley wrote:
>  
>
>>On Wed, 2005-02-23 at 11:53 -0500, Daniel J Walsh wrote:
>>    
>>
>>>Ok try again.
>>>      
>>>
>>Looks good.  Of course, you'll need to update the spec file if you
>>haven't already to depend on versions of libselinux and libsepol that
>>include the necessary support (libselinux >= 1.21.10, libsepol >=
>>1.3.4).
>>    
>>
>
>In case you think this is important...
>load_policy's not working for me re: fixing this issue.
>It says policy loaded, shows 10 users (as opposed to 4 after init).
>Then I restorecon the entire home folder, it properly restores
>unlabeled_t files to staff_home_t, and ...
>
>I try to login, and I get denials that my home folder is unlabeled_t.
>
>I should note that while restorecon changes newly created unlabeled_t
>files to staff_home_t, it does nothing about my home folder (because
>it already says staff_home_dir_t on disk. Yet it says unlabeled_t
>on attempted access even after users are loaded.
>
>P.S. Why are there no SRPMS on dwalsh's repository..
>I found some, but they're not the right ones against rawhide, and I
>don't see sepol there.
>
>  
>
Because I don't put srpms on them.  All packages on my site are just 
what is going to be
in Rawhide the next day.  So I don't bother pullin srpms.

--
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: Strange staff role problems...

[Stephen Smalley]

On Thu, 2005-02-24 at 23:52 -0500, Ivan Gyurdiev wrote:
> In case you think this is important...
> load_policy's not working for me re: fixing this issue.
> It says policy loaded, shows 10 users (as opposed to 4 after init).
> Then I restorecon the entire home folder, it properly restores
> unlabeled_t files to staff_home_t, and ...
> 
> I try to login, and I get denials that my home folder is unlabeled_t.
> 
> I should note that while restorecon changes newly created unlabeled_t
> files to staff_home_t, it does nothing about my home folder (because
> it already says staff_home_dir_t on disk. Yet it says unlabeled_t
> on attempted access even after users are loaded.

The distinction between the on-disk extended attribute value and the
incore inode SID has been discussed previously on the list.  Old SELinux
API allowed applications to directly see the incore inode SID/context;
the forced migration to the xattr API means that they can only see the
on-disk xattr.  End result is that applications like restorecon
sometimes get confused and don't relabel because the on-disk xattr looks
ok.  The force option should likely force a relabel regardless.  Policy
reload doesn't walk the incore inode list to reset any previously
invalid inode SIDs from the unlabeled state.


-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


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