sepol_genusers

sepol_genusers

[Stephen Smalley]

As per the earlier discussions of improving user management, the
genpolusers logic has been moved into a libsepol function,
sepol_genusers(), that can act on an in-memory binary policy image prior
to loading.  The genpolusers utility is now a trivial utility in
libsepol rather than part of the checkpolicy package.  A
selinux_users_path() function has been added to libselinux to allow
programs to get the path to the directory
(/etc/selinux/$SELINUXTYPE/users/) containing the runtime user
configuration files (system.users, local.users) so that they can pass
this path to sepol_genusers().  load_policy has been modified to call
sepol_genusers() prior to policy load in a similar manner to how it
already calls sepol_genbools().  /sbin/init still needs to be modified
in the same manner.

These changes are included in libsepol >= 1.3.5, checkpolicy >= 1.21.4,
libselinux >= 1.21.10, and policycoreutils >= 1.21.16.  Note that the
new load_policy depends on the new libselinux and libsepol for the
selinux_users_path() and sepol_genusers() functions.

-- 
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: sepol_genusers

[Daniel J Walsh]

Ok I have a version of init with the genusers stuff in it.  I am not 
sure of the way we should react to errors though.

What should init do if local.users is missing?  Has bad data in it?  My 
current patch panics the kernel and I don't think that
is a great idea.   IE the user screws up the local.users file and we 
can't boot.

Dan

--
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: sepol_genusers

[Karl MacMillan]

Any reason this shouldn't generate a new policy that is saved to disc? How are
the booleans handled when the config file is corrupt? Also, there doesn't seem
to be a security reason not to continue the boot with the missing users.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134  

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com] 
> Sent: Thursday, February 17, 2005 6:54 PM
> To: Stephen Smalley
> Cc: selinux@tycho.nsa.gov; Karl MacMillan
> Subject: Re: sepol_genusers
> 
> Ok I have a version of init with the genusers stuff in it.  I 
> am not sure of the way we should react to errors though.
> 
> What should init do if local.users is missing?  Has bad data 
> in it?  My current patch panics the kernel and I don't think that
> is a great idea.   IE the user screws up the local.users file and we 
> can't boot.
> 
> Dan
> 


--
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: sepol_genusers

[Stephen Smalley]

On Thu, 2005-02-17 at 21:53 -0500, Karl MacMillan wrote:
> Any reason this shouldn't generate a new policy that is saved to disc? How are
> the booleans handled when the config file is corrupt? Also, there doesn't seem
> to be a security reason not to continue the boot with the missing users.

sepol_genusers(3), like sepol_genbools(3), is acting on an in-memory
binary policy image and generating a new in-memory image for loading
into the kernel just prior to performing the load.  No modification of
the on-disk policy binary file.  That is the point.

-- 
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: sepol_genusers

[Stephen Smalley]

On Thu, 2005-02-17 at 18:54 -0500, Daniel J Walsh wrote:
> What should init do if local.users is missing?  Has bad data in it?  My 
> current patch panics the kernel and I don't think that
> is a great idea.   IE the user screws up the local.users file and we 
> can't boot.

The current sepol_genusers(3) logic should just skip invalid user
entries without returning an error, but does return errors in the cases
of:
- no system.users file
- no local.users file
- overly long line that was truncated (should likely be handled like
invalid user entries instead)
- out of memory while processing

Possibly we could change /sbin/init and load_policy to just load the
original binary policy image in the case where sepol_genusers(3) returns
an error, as it doesn't modify that image during processing - it just
creates a new image.




--
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: sepol_genusers

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Friday, February 18, 2005 8:37 AM
> To: Karl MacMillan
> Cc: 'Daniel J Walsh'; selinux@tycho.nsa.gov
> Subject: RE: sepol_genusers
> 
> On Thu, 2005-02-17 at 21:53 -0500, Karl MacMillan wrote:
> > Any reason this shouldn't generate a new policy that is 
> saved to disc? 
> > How are the booleans handled when the config file is corrupt? Also, 
> > there doesn't seem to be a security reason not to continue 
> the boot with the missing users.
> 
> sepol_genusers(3), like sepol_genbools(3), is acting on an 
> in-memory binary policy image and generating a new in-memory 
> image for loading into the kernel just prior to performing 
> the load.  No modification of the on-disk policy binary file. 
>  That is the point.
>

I know that't the point - I'm questioning whether that is the right approach for
this. For the booleans, the worst case it to fall back on the policy defaults.
For users, there is no fallback other than a previous policy, which in this
model won't have any users either. Why not have the user management tool
generate a new policy (indirectly through a helper, of course)? Really just a
binary policy version of the seuser program (not the X tool or the scripts - the
seuser program that _only_ modifies the policy).

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134  
 
> --
> 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: sepol_genusers

[Stephen Smalley]

On Fri, 2005-02-18 at 09:00 -0500, Karl MacMillan wrote:
> I know that't the point - I'm questioning whether that is the right approach for
> this. For the booleans, the worst case it to fall back on the policy defaults.
> For users, there is no fallback other than a previous policy, which in this
> model won't have any users either. Why not have the user management tool
> generate a new policy (indirectly through a helper, of course)? Really just a
> binary policy version of the seuser program (not the X tool or the scripts - the
> seuser program that _only_ modifies the policy).

I don't quite see the first point; even with this in place, the on-disk
binary policy still has the base set of user definitions (system_u,
user_u, root), which is sufficient for basic operation even if
system.users and/or local.users is corrupted.

The approach you describe is what I originally proposed using the old
genpolusers utility, which generated a new binary policy file from an
existing one and a new set of user configuration files.  But that would
mean that local customization of user definitions will yield a different
binary policy file, thereby invalidating rpm -V checking.

-- 
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: sepol_genusers

[Stephen Smalley]

On Fri, 2005-02-18 at 08:43 -0500, Stephen Smalley wrote:
> Possibly we could change /sbin/init and load_policy to just load the
> original binary policy image in the case where sepol_genusers(3) returns
> an error, as it doesn't modify that image during processing - it just
> creates a new image.

The patch below would make this change for load_policy, so that it will
just fall through to loading the original binary policy image if
sepol_genusers(3) returns an error.

Index: policycoreutils/load_policy/load_policy.c
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policycoreutils/load_policy/load_policy.c,v
retrieving revision 1.11
diff -u -p -r1.11 load_policy.c
--- policycoreutils/load_policy/load_policy.c	17 Feb 2005 15:25:01 -0000	1.11
+++ policycoreutils/load_policy/load_policy.c	18 Feb 2005 14:22:01 -0000
@@ -87,7 +87,8 @@ int main(int argc, char **argv) 
 	ret = sepol_genusers(map, sb.st_size, selinux_users_path(), &data, &data_size);
 	if (ret < 0) {
 		fprintf(stderr, _("%s:  Error while setting user configuration from %s:  %s\n"), argv[0], selinux_users_path(), strerror(errno));
-		exit(2);
+		data = map;
+		data_size = sb.st_size;
 	}
 
 	if (setbools) {

-- 
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: sepol_genusers

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Friday, February 18, 2005 9:08 AM
> To: Karl MacMillan
> Cc: 'Daniel J Walsh'; selinux@tycho.nsa.gov
> Subject: RE: sepol_genusers
> 
> On Fri, 2005-02-18 at 09:00 -0500, Karl MacMillan wrote:
> > I know that't the point - I'm questioning whether that is the right 
> > approach for this. For the booleans, the worst case it to 
> fall back on the policy defaults.
> > For users, there is no fallback other than a previous 
> policy, which in 
> > this model won't have any users either. Why not have the user 
> > management tool generate a new policy (indirectly through a 
> helper, of 
> > course)? Really just a binary policy version of the seuser program 
> > (not the X tool or the scripts - the seuser program that 
> _only_ modifies the policy).
> 
> I don't quite see the first point; even with this in place, 
> the on-disk binary policy still has the base set of user 
> definitions (system_u, user_u, root), which is sufficient for 
> basic operation even if system.users and/or local.users is corrupted.
> 

The policy is not garunteed to have user_u and root, though I guess it likely
will. I guess I am saying that it is possible that the on-disk policy would not
have sufficient users to allow the system to function enough to fix the
corrupted files without entering permissive mode. Careful crafting of the
on-disk policy presumably could prevent this, though. With booleans, the worst
case doesn't seem, to me, to be so extreme, but I guess it would be possible to
have boolean defaults that would render the machine useless.

> The approach you describe is what I originally proposed using 
> the old genpolusers utility, which generated a new binary 
> policy file from an existing one and a new set of user 
> configuration files.  But that would mean that local 
> customization of user definitions will yield a different 
> binary policy file, thereby invalidating rpm -V checking.
>

Ahh. One of the continuing issues raised by policy files being managed by rpm.
Not that I have a better solution.

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134 
 
> --
> 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.