Re: Why are we managing seusers file via libsemanage?

Re: Why are we managing seusers file via libsemanage?

[schaufler-ca.com - Casey Schaufler]

Ivan Gyurdiev wrote:

> I don't understand the way Unix updates
> the password for example - it  doesn't make
> sense to me, I would appreciate an explanation
> from  someone who knows better.


Image a universe with no Internet. A universe
in which DES is sufficiently strong encryption for
any purpose, including DoD classified material.
A universe in which 16bit computing is hot stuff,
where computers store passwords in clear text,
and Gigabyte describes the storage capacity of
the United States.

In that universe storing user ID and password
information in an unstructured flat file, with the
password stored as a one-way DES hash not
only makes sense, it's Brilliant! (Wow, I want a
Guiness now!) The administrator can update
the user information using normal tools like ed,
or even exotic ones like sed, grep, and ex.
Heck, there's even an API for reading the file
(getpwent()) that parses the file for you if you
need to translate uid numbers to user names.
What's more, there's a program (passwd(1))
that carefully allows a user to change her
password -get this- without bothering the
administrator. Incredible.

Unix password management was magical in
its day. It's still good enough to fight off the
dozens of attempts that have been made to
replace it with something "better".

Sigh. You just made me feel old. I'll go back
to my corner now.


------------------------
Casey Schaufler
casey@schaufler-ca.com
650.906.1780








--
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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

>
> Image a universe with no Internet.
... you mean back when people used to read books and stuff, and go out 
of the house to shop!?
Fortunately I can't remember those dark ages....


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

Why are we managing seusers file via libsemanage?

[Daniel J Walsh]

I don't recall why we did this?

I am now thinking this is not a good idea.  People were told to edit the 
/etc/selinux/POLICYTYPE/seusers file to change the default level at 
login, now we do this via libsemanage.  But doing this via libsemanage 
eliminates us from being able to distribute this information via say LDAP.

I think that seusers and setrans.conf should be left as flat files and 
allowed to be distributed via ldap.  We can allow the semanage tool and 
others to modify them and verify the data entry, but not manage them via 
the library.

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: Why are we managing seusers file via libsemanage?

[Joshua Brindle]

Daniel J Walsh wrote:
> I don't recall why we did this?
> 
> I am now thinking this is not a good idea.  People were told to edit the 
> /etc/selinux/POLICYTYPE/seusers file to change the default level at 
> login, now we do this via libsemanage.  But doing this via libsemanage 
> eliminates us from being able to distribute this information via say LDAP.
> 
so that there could be a system + local (combined at commit time) iirc.

the database design of libsemanage should be conducive to distributing 
this info with LDAP and still adding it to the policy at commit time. 
Ivan made the database implementation fairly flexible about changing the 
storage backend while still pulling the data in and using it to rebuild 
policies.

> I think that seusers and setrans.conf should be left as flat files and 
> allowed to be distributed via ldap.  We can allow the semanage tool and 
> others to modify them and verify the data entry, but not manage them via 
> the library.
> 

I'd rather a central point for SELinux management. Also, if not through 
libsemanage the seuser file couldn't be managed through the policy 
server. Further, libsemanage gives the ability to sanity check the input 
  against the policy for error checking at modify time. This should 
potentially cut down on bugs caused by modifying this by hand.

--
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: Why are we managing seusers file via libsemanage?

[Joshua Brindle]

Joshua Brindle wrote:
> Daniel J Walsh wrote:
> 
>> I don't recall why we did this?
>>
>> I am now thinking this is not a good idea.  People were told to edit 
>> the /etc/selinux/POLICYTYPE/seusers file to change the default level 
>> at login, now we do this via libsemanage.  But doing this via 
>> libsemanage eliminates us from being able to distribute this 
>> information via say LDAP.
>>
> so that there could be a system + local (combined at commit time) iirc.
> 
> the database design of libsemanage should be conducive to distributing 
> this info with LDAP and still adding it to the policy at commit time. 
> Ivan made the database implementation fairly flexible about changing the 
> storage backend while still pulling the data in and using it to rebuild 
> policies.
> 
>> I think that seusers and setrans.conf should be left as flat files and 
>> allowed to be distributed via ldap.  We can allow the semanage tool 
>> and others to modify them and verify the data entry, but not manage 
>> them via the library.
>>
> 
> I'd rather a central point for SELinux management. Also, if not through 
> libsemanage the seuser file couldn't be managed through the policy 
> server. Further, libsemanage gives the ability to sanity check the input 
>  against the policy for error checking at modify time. This should 
> potentially cut down on bugs caused by modifying this by hand.
> 

To clarify: The library needs to do the validation no matter what. The 
policy isn't exposed to any userland tools so semanage can't do checking 
itself. So whether the semanage tool writes the file or libsemanage 
writes the file the library does validation, I don't see a compelling 
reason to push this parsing/writing code to the client.

I'd like the policy server to be capable of enforcing access on this 
file or else all the policy access controls are for naught, since the 
seuser file becomes an all-or-nothing point to give permissions to users.

--
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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

>
> To clarify: The library needs to do the validation no matter what. The 
> policy isn't exposed to any userland tools so semanage can't do 
> checking itself. 

Not entirely true - the client could query the necessary information via 
semanage, and do validation itself. You can take the entire 
seuser_validate function, take it out of semanage, change it a little 
bit, and put put in a transaction, and it would work just fine.

> So whether the semanage tool writes the file or libsemanage writes the 
> file the library does validation, I don't see a compelling reason to 
> push this parsing/writing code to the client.
My reasoning is - whether the info is stored in LDAP or not is an 
implementation detail. It should not affect the data model that we're 
working with. It makes sense to put seusers in libsemanage, because that 
allows management of all selinux-related things from a single shared 
library in a consistent interface, with shared transactions and 
validation. It's also a good point for integration with the policy server.

In other words, libsemanage should pull the data out of LDAP, hiding the 
implementation details. I'm not sure how it would do that exactly - 
dlopen another library, call outside tool, will have to look into that. 
I've tried to make the libsemanage part of it flexible, to deal with 
this issue eventually. However, I think libsemanage should be the 
management frontend. Letting the storage backend determine interface 
structure seems like the wrong approach - either the interface makes 
sense, or it doesn't - why should we change it, if the info is backed in 
LDAP?


--
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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

Ivan Gyurdiev wrote:
>>
>> To clarify: The library needs to do the validation no matter what. 
>> The policy isn't exposed to any userland tools so semanage can't do 
>> checking itself. 
>
> Not entirely true - the client could query the necessary information 
> via semanage, and do validation itself. You can take the entire 
> seuser_validate function, take it out of semanage, change it a little 
> bit, and put put in a transaction, and it would work just fine.
>
Well, allright... that used to be true before I put in the MLS checks. 
Now seuser validation would require a backend-neutral way to check mls 
dominance and mls validity, which libsemanage does not provide at the 
current time (we could add it, but it doesn't exist right now, client 
has to assume direct backend, no policy server).


--
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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

>> I don't recall why we did this?
>>
>> I am now thinking this is not a good idea.  People were told to edit 
>> the /etc/selinux/POLICYTYPE/seusers file to change the default level 
>> at login, now we do this via libsemanage.  But doing this via 
>> libsemanage eliminates us from being able to distribute this 
>> information via say LDAP.
>>
> so that there could be a system + local (combined at commit time) iirc.
Actually that's a bad example for seusers, which are the one case where 
there is no system + local currently...
>
> the database design of libsemanage should be conducive to distributing 
> this info with LDAP and still adding it to the policy at commit time. 
> Ivan made the database implementation fairly flexible about changing 
> the storage backend while still pulling the data in and using it to 
> rebuild policies.
Yes, hopefully we should be able to write an LDAP backend for this data 
model.



--
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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

Daniel J Walsh wrote:
> I don't recall why we did this?
>
> I am now thinking this is not a good idea.  People were told to edit 
> the /etc/selinux/POLICYTYPE/seusers file to change the default level 
> at login, now we do this via libsemanage.  But doing this via 
> libsemanage eliminates us from being able to distribute this 
> information via say LDAP.
I think the issue of management and of distribution are completely 
independent from each other (or if not, they should be made so). 
Distribution gets the data from A to B. Management interprets the data, 
and decides what to do with it.

I don't understand the way Unix updates the password for example - it 
doesn't make sense to me, I would appreciate an explanation from someone 
who knows better. It provides a shared read interface on the passwd file 
(with backend switching via nss). It doesn't provide a shared write 
interface - why? That seems to me like a design mistake, where 
distribution/backend is tied to management. Why should I care where the 
password is kept if all I want to do is update it. I don't think we 
should replicate that behavior, and copy the read/write code in 10 
places, like it's done for passwd - not until it's clear why this is the 
correct way to go.



--
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: Why are we managing seusers file via libsemanage?

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> Daniel J Walsh wrote:
>> I don't recall why we did this?
>>
>> I am now thinking this is not a good idea.  People were told to edit 
>> the /etc/selinux/POLICYTYPE/seusers file to change the default level 
>> at login, now we do this via libsemanage.  But doing this via 
>> libsemanage eliminates us from being able to distribute this 
>> information via say LDAP.
> I think the issue of management and of distribution are completely 
> independent from each other (or if not, they should be made so). 
> Distribution gets the data from A to B. Management interprets the 
> data, and decides what to do with it.
>
> I don't understand the way Unix updates the password for example - it 
> doesn't make sense to me, I would appreciate an explanation from 
> someone who knows better. It provides a shared read interface on the 
> passwd file (with backend switching via nss). It doesn't provide a 
> shared write interface - why? That seems to me like a design mistake, 
> where distribution/backend is tied to management. Why should I care 
> where the password is kept if all I want to do is update it. I don't 
> think we should replicate that behavior, and copy the read/write code 
> in 10 places, like it's done for passwd - not until it's clear why 
> this is the correct way to go.
>
>
Ok well the seusers file should indicate that it is machine generated 
and should not be edited then, or can it be eliminated all together.  
Users will edit this file...

We still need a mechanism for managing setrans.conf but I understand why 
that is separate from libsemanage currently.  I also think we need to 
look into a  semachine type interface that indicates that maximum 
security level for a particular machine.


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: Why are we managing seusers file via libsemanage?

[Ivan Gyurdiev]

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


> Ok well the seusers file should indicate that it is machine generated 
> and should not be edited then, or can it be eliminated all together.  
> Users will edit this file...
Patch attached - please also add the  header into the initial seusers 
file that gets installed, and into file_contexts.template in the policy.




[-- Attachment #2: libsemanage.autogen_header.diff --]
[-- Type: text/x-patch, Size: 754 bytes --]

diff -Naurp --exclude-from excludes old/libsemanage/src/database_file.c new/libsemanage/src/database_file.c
--- old/libsemanage/src/database_file.c	2006-01-17 09:11:06.000000000 -0700
+++ new/libsemanage/src/database_file.c	2006-01-17 11:26:15.000000000 -0700
@@ -159,6 +159,14 @@ static int dbase_file_flush(
 	}
 	__fsetlocking(str, FSETLOCKING_BYCALLER);
 
+	if (fprintf(str, "# This file is auto-generated by libsemanage\n"
+	                   "# Please use the semanage command to make "
+	                   "changes\n\n") < 0) {
+
+		ERR(handle, "could not write file header for %s", fname);
+		goto err;
+	}
+
 	for (ptr = dbase->llist.cache_tail; ptr != NULL; ptr = ptr->prev) {
 		if (rftable->print(handle, ptr->data, str) < 0)
 			goto err;