Restorecon script

Restorecon script

[Ivan Gyurdiev]

Any comments on the following script?
It's a profile script, to be shipped with selinux-policy-strict, 
executed per login shell. It hardcodes the applications, 
unfortunately, but does what we want for right now 
(at least a temp. solution, unless someone has a better one?)
Also, user needs to start a login shell to get it to run.

#!/bin/bash

([ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled) || exit

DIRS=" \
/tmp/.ICE-unix \
/tmp/orbit-$USER \
$HOME/.fonts \
$HOME/.fonts/auto \
$HOME/.gnome2 \
$HOME/.gnome2/share/fonts \
$HOME/.gnome2/share/cursor-fonts \
$HOME/.gnome2_private \
$HOME/.mozilla \
$HOME/.evolution \
$HOME/.thunderbird \
"

UNIQUE_DIRS=" \
/tmp/.ICE-unix \
/tmp/orbit-$USER \
$HOME/.fonts \
$HOME/.gnome2 \
$HOME/.gnome2_private \
$HOME/.mozilla \
$HOME/.evolution \
$HOME/.thunderbird \
"

for DIR in $DIRS; do
[ -d $DIR ] || mkdir -p $DIR
done

RESTORED=`/sbin/restorecon -v $UNIQUE_DIRS 2>&1`
if [ ! -z "$RESTORED" ]; then
        /sbin/restorecon -R `echo "$RESTORED" | awk '{ print $3 }'`
fi



--
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: Restorecon script

[Joshua Brindle]

Ivan Gyurdiev wrote:

>Any comments on the following script?
>It's a profile script, to be shipped with selinux-policy-strict, 
>executed per login shell. It hardcodes the applications, 
>unfortunately, but does what we want for right now 
>(at least a temp. solution, unless someone has a better one?)
>Also, user needs to start a login shell to get it to run.
>  
>
What problem is this solving? In general relabeling isn't something that 
should be done without careful attention, especially when automated. 
User home directories shouldn't have incorrect labels is care is taken 
(ie, skel contains the directories you'd be relabeling anyway and they 
are labeled correctly when the user is added).

Joshua Brindle

--
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: Restorecon script

[Ivan Gyurdiev]

> What problem is this solving?

It is solving the problem of labeling things properly in /tmp and /home
(according to recent policy changes, which I've been working on).
This cannot be accomplished by either inheriting the parent's context,
(because it's not the same), or by file_type_auto_trans, because of
ambiguity - same type change rule matches multiple target types.
You can see details of what I mean in the thread "file_type_auto_trans
is not sufficient" on selinux@tycho.nsa.gov.

It can be solved by setfscreate code in the application, but
that's worse - intrusive code in multiple applications.

Creating folders ahead of time is the most acceptable solution so far.
I'm not sure how exactly this should be done, but some sort of simple 
script like this is one possibility. 

>  In general relabeling isn't something that 
> should be done without careful attention, especially when automated. 

I agree.

> User home directories shouldn't have incorrect labels is care is taken 
> (ie, skel contains the directories you'd be relabeling anyway and they 
> are labeled correctly when the user is added).

skel is populated when installing individual applications, and 
that doesn't fix the labels for existing users, only for newly 
created users. Also, that doesn't address /tmp.
==============

Here's a new script:

#!/bin/bash

([ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled) || exit

DIRS=" \
/tmp/orbit-$USER \
$HOME/.fonts \
$HOME/.fonts/auto \
$HOME/.gnome2 \
$HOME/.gnome2/share/fonts \
$HOME/.gnome2/share/cursor-fonts \
$HOME/.gnome2_private \
$HOME/.mozilla \
$HOME/.evolution \
$HOME/.thunderbird \
"

for DIR in $DIRS; do
[ -d $DIR ] || mkdir -m 700 -p $DIR
done

RESTORED=`/sbin/restorecon -v $DIRS 2>&1`
if [ ! -z "$RESTORED" ]; then
        RESULT=`echo "$RESTORED" | awk '{ print $3 }'`
        echo "Restoring SELinux context for:"
        echo $RESULT | sed 's| |\n|g'
        /sbin/restorecon -R $RESULT
fi




--
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: Restorecon script

[Steve G]

Hi,

>Creating folders ahead of time is the most acceptable solution so far.

What if the machine doesn't have X installed? (Such as a server.)

>I'm not sure how exactly this should be done, but some sort of simple 
>script like this is one possibility. 

How about walking the list of dirs and if they exist, do a restorecon? I'm
assuming this script is going to be called via /etc/bashrc?

-Steve Grubb


		
__________________________________ 
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html

--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 06:52 -0700, Steve G wrote:
> Hi,
> 
> >Creating folders ahead of time is the most acceptable solution so far.
> 
> What if the machine doesn't have X installed? (Such as a server.)

Then folders related to X have no need to be there.
That's unfortunate, but it is a simple solution for now.
The alternative would be to break up the directories we want
to create in different rpm packages, and then reassemble them
in a single call to restorecon (since we can't afford to call
restorecon for each app - it takes forever). 

> >I'm not sure how exactly this should be done, but some sort of simple 
> >script like this is one possibility. 
> 
> How about walking the list of dirs and if they exist, do a restorecon? I'm
> assuming this script is going to be called via /etc/bashrc?

One of the goals of this script is to create the directories
if they do not exist. If not, the applications themselves create them,
and create them with the wrong context.



--
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: Restorecon script

[Joshua Brindle]

On Thu, 2005-06-09 at 22:32 -0400, Ivan Gyurdiev wrote:
> > What problem is this solving?
> 
> It is solving the problem of labeling things properly in /tmp and /home
> (according to recent policy changes,

relabeling at policy modification time is much better than automated
relabeling when a user logs in

>  which I've been working on).
> This cannot be accomplished by either inheriting the parent's context,
> (because it's not the same), or by file_type_auto_trans, because of
> ambiguity - same type change rule matches multiple target types.
> You can see details of what I mean in the thread "file_type_auto_trans
> is not sufficient" on selinux@tycho.nsa.gov.
> 
> It can be solved by setfscreate code in the application, but
> that's worse - intrusive code in multiple applications.
> 

it can also be solved by properly structuring directories, either by
application configuration or if necessary modifying the application in a
much less intrusive way (this was mentioned on that thread I believe)

> Creating folders ahead of time is the most acceptable solution so far.
> I'm not sure how exactly this should be done, but some sort of simple 
> script like this is one possibility. 
> 

scripts that install stuff to skel maybe should be responsible for
adding them to user dirs and labeling properly. This would be a trusted
app (rpm or whatever) instead of a user shell script

> >  In general relabeling isn't something that 
> > should be done without careful attention, especially when automated. 
> 
> I agree.
> 
> > User home directories shouldn't have incorrect labels is care is taken 
> > (ie, skel contains the directories you'd be relabeling anyway and they 
> > are labeled correctly when the user is added).
> 
> skel is populated when installing individual applications, and 
> that doesn't fix the labels for existing users, only for newly 
> created users. Also, that doesn't address /tmp.
> ==============

response above 




--
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: Restorecon script

[Stephen Smalley]

On Fri, 2005-06-10 at 12:05 -0400, Joshua Brindle wrote:
> scripts that install stuff to skel maybe should be responsible for
> adding them to user dirs and labeling properly. This would be a trusted
> app (rpm or whatever) instead of a user shell script

You have to be careful in that case, as that trusted app becomes an
obvious target for attack and it is acting on paths into user-writable
directories.  One benefit of running it in the user's context (via the
shell script or when the app is first run by the user and initially
creates these files) is that the relabeling can be confined to the
user's types and there is no risk of misuse of privilege.
 
-- 
Stephen Smalley
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Stephen Smalley
> Sent: Friday, June 10, 2005 12:11 PM
> To: Joshua Brindle
> Cc: Ivan Gyurdiev; Daniel J Walsh; SELinux; selinux-dev@tresys.com
> Subject: Re: Restorecon script
> 
> On Fri, 2005-06-10 at 12:05 -0400, Joshua Brindle wrote:
> > scripts that install stuff to skel maybe should be responsible for
> > adding them to user dirs and labeling properly. This would be a trusted
> > app (rpm or whatever) instead of a user shell script
> 
> You have to be careful in that case, as that trusted app becomes an
> obvious target for attack and it is acting on paths into user-writable
> directories.  One benefit of running it in the user's context (via the
> shell script or when the app is first run by the user and initially
> creates these files) is that the relabeling can be confined to the
> user's types and there is no risk of misuse of privilege.
> 

It would probably still be better practice to execute the script in the user's
domain or a limited version of that domain from the trusted domain (e.g. rpm) -
if nothing else that means that the relabeling happens less often. Of course, if
the user's domain has this relabel privilege anyway, having the privileged
domain doing the relabeling, either directly or indirectly, doesn't really help
at all. The user can just install / write the script themselves. Removing the
relabeling privilege from the user is probably difficult and they can just copy
files into the appropriate directories and get the same result (assuming type
transition rules are in place).

Karl

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

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



--
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: Restorecon script

[Stephen Smalley]

On Fri, 2005-06-10 at 13:44 -0400, Karl MacMillan wrote:
> It would probably still be better practice to execute the script in the user's
> domain or a limited version of that domain from the trusted domain (e.g. rpm) -
> if nothing else that means that the relabeling happens less often. Of course, if
> the user's domain has this relabel privilege anyway, having the privileged
> domain doing the relabeling, either directly or indirectly, doesn't really help
> at all. The user can just install / write the script themselves. Removing the
> relabeling privilege from the user is probably difficult and they can just copy
> files into the appropriate directories and get the same result (assuming type
> transition rules are in place).

These files are under the user's control anyway; the purpose of labeling
them with their own type is to allow particular user apps to access them
without allowing those apps to access all of the user's files.

-- 
Stephen Smalley
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: Restorecon script

[Ivan Gyurdiev]

> These files are under the user's control anyway; the purpose of labeling
> them with their own type is to allow particular user apps to access them
> without allowing those apps to access all of the user's files.

By the way, I have addressed the need for { relabelto relabelfrom } on
various types, by adding those rules for each individual domain
that we're currently relabeling in the script.

An alternative is to add { relabelto relabelfrom } on all of
$1_file_type, but I wasn't sure whether or not that's something
we want to do.



--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Friday, June 10, 2005 1:42 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; Ivan Gyurdiev; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> On Fri, 2005-06-10 at 13:44 -0400, Karl MacMillan wrote:
> > It would probably still be better practice to execute the script in the
> user's
> > domain or a limited version of that domain from the trusted domain (e.g.
> rpm) -
> > if nothing else that means that the relabeling happens less often. Of
> course, if
> > the user's domain has this relabel privilege anyway, having the privileged
> > domain doing the relabeling, either directly or indirectly, doesn't really
> help
> > at all. The user can just install / write the script themselves. Removing
> the
> > relabeling privilege from the user is probably difficult and they can just
> copy
> > files into the appropriate directories and get the same result (assuming
> type
> > transition rules are in place).
> 
> These files are under the user's control anyway; the purpose of labeling
> them with their own type is to allow particular user apps to access them
> without allowing those apps to access all of the user's files.
> 

Or only giving the read access I assume. So we are not trying to protect from
malicious code running in the user's domain disclosing data by relabeling to
httpd_user_content_t, for example? If that is the case the user domain is
trusted to manage these files at their discretion. One point I was trying to
make is that this probably has to be the case as removing relabel permission
from the user domain has no impact.

Relabeling on every login still seems excessive and based on what this policy is
trying to accomplish perhaps not a good idea. If the files are under the user's
control then they should be fully under their control. What if I am waiting to
relabel my ~/public_html until I am done with the content and this administrator
controlled script does it for me?

Karl

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

> --
> Stephen Smalley
> 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: Restorecon script

[Stephen Smalley]

On Fri, 2005-06-10 at 14:06 -0400, Karl MacMillan wrote:
> Or only giving the read access I assume. So we are not trying to protect from
> malicious code running in the user's domain disclosing data by relabeling to
> httpd_user_content_t, for example?

Not presently, no. 

>  If that is the case the user domain is
> trusted to manage these files at their discretion. One point I was trying to
> make is that this probably has to be the case as removing relabel permission
> from the user domain has no impact.

Right, malicious code could just create/write to httpd_user_content_t;
it doesn't need relabel permission. Only way to avoid that is to
restrict all creation of web content through a controlled app that
confirms user intent, but at that point, you are unlikely to be using
~/public_html at all in your web setup.

> Relabeling on every login still seems excessive and based on what this policy is
> trying to accomplish perhaps not a good idea. If the files are under the user's
> control then they should be fully under their control. What if I am waiting to
> relabel my ~/public_html until I am done with the content and this administrator
> controlled script does it for me?

IMHO, you shouldn't be putting it into ~/public_html until you are ready
for it to be exported; that doesn't seem to be different from current
usage.

A larger concern might be that you don't want the restorecon to clobber
local customization, e.g. to distinguish read-only content under
~/public_html from content that can be modified by a user CGI.  I think
that the customizable types support would actually prevent that, as
restorecon won't touch those types by default.

One advantage of relabeling on login (similar to relabeling from
rc.sysinit that is presently done for certain files) is that it helps
counter type lossage that may occur over time due to direct user
manipulation (e.g. moving aside your public_html and dropping in a new
tree, but failing to restorecon it manually) or under targeted policy.
Obviously it is better to proactively preserve the types in the first
place, but we aren't there yet.

-- 
Stephen Smalley
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Friday, June 10, 2005 2:05 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; Ivan Gyurdiev; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> IMHO, you shouldn't be putting it into ~/public_html until you are ready
> for it to be exported; that doesn't seem to be different from current
> usage.
> 

Weak example, I agree, but I think that the concept holds.

> A larger concern might be that you don't want the restorecon to clobber
> local customization, e.g. to distinguish read-only content under
> ~/public_html from content that can be modified by a user CGI.  I think
> that the customizable types support would actually prevent that, as
> restorecon won't touch those types by default.
> 
> One advantage of relabeling on login (similar to relabeling from
> rc.sysinit that is presently done for certain files) is that it helps
> counter type lossage that may occur over time due to direct user
> manipulation (e.g. moving aside your public_html and dropping in a new
> tree, but failing to restorecon it manually) or under targeted policy.
> Obviously it is better to proactively preserve the types in the first
> place, but we aren't there yet.
> 

I don't disagree, but having the problems magically fixed by logging in seems
strange and potentially confusing to users. This is all trying to make
everything transparent to the user. I hate to say it, but I think that it will
ultimately not be transparent and in that case maybe the best option is the
least number of implicit operations and user involvement.

Karl 

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

> --
> Stephen Smalley
> 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: Restorecon script

[Ivan Gyurdiev]

> Or only giving the read access I assume. So we are not trying to protect from
> malicious code running in the user's domain disclosing data by relabeling to
> httpd_user_content_t, for example? 

Malicious code should not be running in the user_t domain.
the user_t domain is highly privileged, and we should try to keep
malicious code out of it. That's why most vulnerable applications
are being placed in restricted domains.

I don't think there's much we can do to protect from the user domain,
since it also represents the actual user, working from the terminal,
which must be allowed to do what he/she desires.

> If that is the case the user domain is
> trusted to manage these files at their discretion. One point I was trying to
> make is that this probably has to be the case as removing relabel permission
> from the user domain has no impact.

The user domain actually didn't have too many relabel privileges, until
I added them just now to our version of policy.

> Relabeling on every login still seems excessive and based on what this policy is
> trying to accomplish perhaps not a good idea.

Please note that *recursive* relabeling is only performed if
relabeling of a top level directory (in that list) fails. Therefore
it's not all that slow. Do you have an alternative proposal?

>  If the files are under the user's
> control then they should be fully under their control. 

The way to do that is by integrating ugly libselinux code into
a large number of applications. I think this will not be 
well received by the upstream developers at this time.

> What if I am waiting to
> relabel my ~/public_html until I am done with the content and this administrator
> controlled script does it for me?

The script is only invoked when you launch a login shell (this is
actually a problem). Also, it does not do anything with public_html.



--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 2:21 PM
> To: Karl MacMillan
> Cc: 'Stephen Smalley'; 'Joshua Brindle'; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> 
> > Or only giving the read access I assume. So we are not trying to protect
> from
> > malicious code running in the user's domain disclosing data by relabeling to
> > httpd_user_content_t, for example?
> 
> Malicious code should not be running in the user_t domain.
> the user_t domain is highly privileged, and we should try to keep
> malicious code out of it. That's why most vulnerable applications
> are being placed in restricted domains.
> 

All applications are vulnerable and malicious code will run in this domain at
some point. This is about what happens when that eventually happens. I'm just
clarifying what the goals of these changes are.

> I don't think there's much we can do to protect from the user domain,
> since it also represents the actual user, working from the terminal,
> which must be allowed to do what he/she desires.
> 

Depends on the system - not all users get to do what they want on all systems .
. .

> > If that is the case the user domain is
> > trusted to manage these files at their discretion. One point I was trying to
> > make is that this probably has to be the case as removing relabel permission
> > from the user domain has no impact.
> 
> The user domain actually didn't have too many relabel privileges, until
> I added them just now to our version of policy.
> 
> > Relabeling on every login still seems excessive and based on what this
> policy is
> > trying to accomplish perhaps not a good idea.
> 
> Please note that *recursive* relabeling is only performed if
> relabeling of a top level directory (in that list) fails. Therefore
> it's not all that slow. Do you have an alternative proposal?
> 

I'm not concerned about the performance. Relabeling always has risks and
complicates analysis of security policies - I think it is best avoided except
under special circumstances. This is really the point that started this whole
thread - relabeling should be treated as a special case if at all possible.

The alternative is to do this at package installation time. This would allow,
for example, for an admin to verify that it is safe to relabel and potentially
take the system off line.

> >  If the files are under the user's
> > control then they should be fully under their control.
> 
> The way to do that is by integrating ugly libselinux code into
> a large number of applications. I think this will not be
> well received by the upstream developers at this time.
> 
> > What if I am waiting to
> > relabel my ~/public_html until I am done with the content and this
> administrator
> > controlled script does it for me?
> 
> The script is only invoked when you launch a login shell (this is
> actually a problem). Also, it does not do anything with public_html.

Public_html is just an example - replace it with .ssh if you want.

Karl

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



--
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: Restorecon script

[Ivan Gyurdiev]

> All applications are vulnerable and malicious code will run in this domain at
> some point. This is about what happens when that eventually happens. I'm just
> clarifying what the goals of these changes are.

The way to fix that is to put the applications in a restricted domain,
not to make user_t that restricted domain, by refusing to grant the
user relabel rights to files that he/she should have access to.

> > Please note that *recursive* relabeling is only performed if
> > relabeling of a top level directory (in that list) fails. Therefore
> > it's not all that slow. Do you have an alternative proposal?
> > 
> 
> I'm not concerned about the performance. Relabeling always has risks and
> complicates analysis of security policies - I think it is best avoided except
> under special circumstances. This is really the point that started this whole
> thread - relabeling should be treated as a special case if at all possible.

The script was mostly concerned with creating things in the right
context to begin with. It would be easy to modify it to not relabel 
anything if it locates a folder that's in the wrong context, but 
I'm not sure whether that should be done - seems to me like
the wrong context should be fixed.

> The alternative is to do this at package installation time. This would allow,
> for example, for an admin to verify that it is safe to relabel and potentially
> take the system off line.

How exactly would this be done at installation time, in such a manner
as to account for existing 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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 4:46 PM
> To: Karl MacMillan
> Cc: 'Stephen Smalley'; 'Joshua Brindle'; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> 
> > All applications are vulnerable and malicious code will run in this domain
> at
> > some point. This is about what happens when that eventually happens. I'm
> just
> > clarifying what the goals of these changes are.
> 
> The way to fix that is to put the applications in a restricted domain,
> not to make user_t that restricted domain, by refusing to grant the
> user relabel rights to files that he/she should have access to.
> 

This has nothing to do with whether the user should or should not have access -
it is about limiting the trust placed in code running on the user's behalf.

Creating more least-privilege code limits the damage from malicious code,
certainly, but in this case it doesn't fix all problems. Some code will be run
in the user domain that will be exploitable or the user will simply run a
Trojan. At that point the malicious code running in user_t can, for example,
disclose sensitive user data by either moving it or relabeling it so that an
application like apache can read it. This can potentially be addressed but it
will be enormously difficult and time consuming.

> > > Please note that *recursive* relabeling is only performed if
> > > relabeling of a top level directory (in that list) fails. Therefore
> > > it's not all that slow. Do you have an alternative proposal?
> > >
> >
> > I'm not concerned about the performance. Relabeling always has risks and
> > complicates analysis of security policies - I think it is best avoided
> except
> > under special circumstances. This is really the point that started this
> whole
> > thread - relabeling should be treated as a special case if at all possible.
> 
> The script was mostly concerned with creating things in the right
> context to begin with. It would be easy to modify it to not relabel
> anything if it locates a folder that's in the wrong context, but
> I'm not sure whether that should be done - seems to me like
> the wrong context should be fixed.
> 
> > The alternative is to do this at package installation time. This would
> allow,
> > for example, for an admin to verify that it is safe to relabel and
> potentially
> > take the system off line.
> 
> How exactly would this be done at installation time, in such a manner
> as to account for existing users?

A post install script that creates directories and/or relabels existing
directories.

Karl

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



--
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: Restorecon script

[Ivan Gyurdiev]

> Creating more least-privilege code limits the damage from malicious code,
> certainly, but in this case it doesn't fix all problems. Some code will be run
> in the user domain that will be exploitable or the user will simply run a
> Trojan. At that point the malicious code running in user_t can, for example,
> disclose sensitive user data by either moving it or relabeling it so that an
> application like apache can read it. This can potentially be addressed but it
> will be enormously difficult and time consuming.

ROLE_t has access to cp, which equates a relabel, does it not?
If the user can read the file... 

> A post install script that creates directories and/or relabels existing
> directories.

... ok



--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 5:48 PM
> To: Karl MacMillan
> Cc: 'Stephen Smalley'; 'Joshua Brindle'; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> 
> > Creating more least-privilege code limits the damage from malicious code,
> > certainly, but in this case it doesn't fix all problems. Some code will be
> run
> > in the user domain that will be exploitable or the user will simply run a
> > Trojan. At that point the malicious code running in user_t can, for example,
> > disclose sensitive user data by either moving it or relabeling it so that an
> > application like apache can read it. This can potentially be addressed but
> it
> > will be enormously difficult and time consuming.
> 
> ROLE_t has access to cp, which equates a relabel, does it not?
> If the user can read the file...
> 

I'm confused . . . you seem to be disagreeing by agreeing. That is exactly the
point I've been hammering on - we have no protection from malicious code in
ROLE_t disclosing user data. From my previous mail:

> Removing the relabeling privilege from the user is probably difficult and they
> can just copy files into the appropriate directories and get the same result
> (assuming type transition rules are in place).

Karl

> > A post install script that creates directories and/or relabels existing
> > directories.
> 
> ... ok

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



--
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: Restorecon script

[Ivan Gyurdiev]

> 
> I'm confused . . . you seem to be disagreeing by agreeing. 

That's exactly what I'm doing. 
You're arguing against giving ROLE_t the right to relabel certain
files. I say the battle is futile, and applications need to be moved
out of ROLE_t to achieve any kind of security. ROLE_t is just too 
broad an umbrella for grouping applications - I prefer to think of it
as a domain for apps without a policy yet.

Anyway, I agree that rpm would be better suited for creating
directories - mostly because of resource tracking per application,
and the login shell requirement....so I surrender the argument.




--
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: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 02:21:01PM -0400, Ivan Gyurdiev wrote:
> >  If the files are under the user's
> > control then they should be fully under their control. 
> 
> The way to do that is by integrating ugly libselinux code into
> a large number of applications. I think this will not be 
> well received by the upstream developers at this time.
 
 at some point, i believe that they are going to have to.

 developers use "chown()" and "chgrp()" etc. all the time.

 the people developing selinux have done a _great_ job designing
 something that covers nearly all of the cases.

 ... idea for you.
 
 how about "auto-file-domaining" on chown() and chgrp(), in
 a similar way that exec() performs auto-domain-transitioning?

 l.


--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 21:18 +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 10, 2005 at 02:21:01PM -0400, Ivan Gyurdiev wrote:
> > >  If the files are under the user's
> > > control then they should be fully under their control. 
> > 
> > The way to do that is by integrating ugly libselinux code into
> > a large number of applications. I think this will not be 
> > well received by the upstream developers at this time.
>  
>  at some point, i believe that they are going to have to.
> 
>  developers use "chown()" and "chgrp()" etc. all the time.

This is different from chown and chgrp, because unlike chown and
chgrp, SElinux centralizes labeling decisions using regular
expressions. This makes the code slower.
Also, chown and chgrp are part of POSIX, whereas SElinux is not,
which makes the code non-portable. Also, SElinux is
not yet widely used, which means it has to be if-deffed out.
Also, it requires a library to be linked in, while chown
and chmod do not (other than libc).

Also, Stephen has mentioned that the current setfscreatecon
code does not work well with multiple threads.

Due to all of the above, adding SELinux code in applications
currently seems like a bad idea.

>  how about "auto-file-domaining" on chown() and chgrp(), in
>  a similar way that exec() performs auto-domain-transitioning?

Automatic transitions already exist, and are not sufficient.
A full regexp match is too slow to perform by default in all
cases.


--
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: Restorecon script

[Valdis.Kletnieks]

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

On Fri, 10 Jun 2005 21:18:14 BST, Luke Kenneth Casson Leighton said:

>  how about "auto-file-domaining" on chown() and chgrp(), in
>  a similar way that exec() performs auto-domain-transitioning?

Ouch.

The major conceptual difficulty is that exec() is a logical and obvious place
to change domains in a manner similar to set(u|g)id binaries. Programmers are
*used* to the concept that "exec() splats everything" to the point that they
sometimes get bit when they encounter something that *isnt* reset by exec()
(the open file descriptor table is a common example).

However, that model doesn't extend easily to chown/chgrp.  The problem is twofold:

1) You may want this auto-file to happen in programs that have absolutely no
business going anywhere *near* chown/chgrp. (I'll go a step further and say
that doing this behind-the-scenes magic to a program that's *allowed* to
chown(), instead of fixing the program to DTRT, is a security mess just waiting
to happen).

2) Even if the code *is* doing chown/chgrp, you end up with lots of "magic" -
two chown() calls to set the same "user" may set different security contexts,
and two chown() calls that set different users may set the same context.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 05:05:55PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 10 Jun 2005 21:18:14 BST, Luke Kenneth Casson Leighton said:
> 
> >  how about "auto-file-domaining" on chown() and chgrp(), in
> >  a similar way that exec() performs auto-domain-transitioning?
> 
> Ouch.

 ... just a thought :)

 l.


--
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: Restorecon script

[Joshua Brindle]

On Fri, 2005-06-10 at 14:21 -0400, Ivan Gyurdiev wrote:
<snip>
> 
> The way to do that is by integrating ugly libselinux code into
> a large number of applications. I think this will not be 
> well received by the upstream developers at this time.
> 

which is why the patches to upstream developers should either make the
directory structure the app uses configurable or change it to use
multiple directories. This is a good idea anyway, putting objects with
different security properties into different places. This should be much
more acceptable to an upstream developer than integrating "ugly
libselinux code"

> > What if I am waiting to
> > relabel my ~/public_html until I am done with the content and this administrator
> > controlled script does it for me?
> 
> The script is only invoked when you launch a login shell (this is
> actually a problem). Also, it does not do anything with public_html.
> 
> 
Not sure if this is the problem you are referring but it seems awefully
awkward to me to require a user to open a login shell after installing
an app. SELinux on Red Hat is suppose to be transparent and this clearly
is not. If the rpm added the directories to user homedirs and labeled
them the net effect would be the same. I really question how this can be
thought of as anything other than an administrative issue. The admin
installs the app, the app needs it's resources labeled, the admin (by
way of rpm) should label the resources, I can't see how any other way
makes sense.





--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 17:03 -0400, Joshua Brindle wrote:
> On Fri, 2005-06-10 at 14:21 -0400, Ivan Gyurdiev wrote:
> <snip>
> > 
> > The way to do that is by integrating ugly libselinux code into
> > a large number of applications. I think this will not be 
> > well received by the upstream developers at this time.
> > 
> 
> which is why the patches to upstream developers should either make the
> directory structure the app uses configurable or change it to use
> multiple directories. This is a good idea anyway, putting objects with
> different security properties into different places. This should be much
> more acceptable to an upstream developer than integrating "ugly
> libselinux code"

I don't see how it's possible to eliminate the problem of ambiguity
by creating more directories. Can you demonstrate an example,
where you do not need to create anything ahead of time,
and can rely on the app to create its own folders?

If you need to pre-create stuff, then you won't need selinux-aware
code in your apps. That's the approach we're taking.

Assuming this could be made to work (which I don't see how it can),
I don't see why it's a good idea to force directory structure based on
policy. Directories are made for grouping things, and security
properties may or may not be the criterion you'd like to use
for grouping. For example, the /tmp directory groups temporary files,
which obviously need to be of different contexts - hence this entire
problem.

>  SELinux on Red Hat is suppose to be transparent and this clearly
> is not.

This is strict policy only, not targeted.

>  If the rpm added the directories to user homedirs and labeled
> them the net effect would be the same. I really question how this can be
> thought of as anything other than an administrative issue. The admin
> installs the app, the app needs it's resources labeled, the admin (by
> way of rpm) should label the resources, I can't see how any other way
> makes sense.

Okay, I agree with this solution. It's not very clear how to implement
right now, but it is the right thing to do, eventually.



--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Ivan Gyurdiev
> Sent: Friday, June 10, 2005 5:31 PM
> To: Joshua Brindle
> Cc: Karl MacMillan; 'Stephen Smalley'; 'Daniel J Walsh'; 'SELinux'; selinux-
> dev@tresys.com
> Subject: RE: Restorecon script
> 
> On Fri, 2005-06-10 at 17:03 -0400, Joshua Brindle wrote:
> > On Fri, 2005-06-10 at 14:21 -0400, Ivan Gyurdiev wrote:
> > <snip>
> > >
> > > The way to do that is by integrating ugly libselinux code into
> > > a large number of applications. I think this will not be
> > > well received by the upstream developers at this time.
> > >
> >
> > which is why the patches to upstream developers should either make the
> > directory structure the app uses configurable or change it to use
> > multiple directories. This is a good idea anyway, putting objects with
> > different security properties into different places. This should be much
> > more acceptable to an upstream developer than integrating "ugly
> > libselinux code"
> 
> I don't see how it's possible to eliminate the problem of ambiguity
> by creating more directories. Can you demonstrate an example,
> where you do not need to create anything ahead of time,
> and can rely on the app to create its own folders?
> 
> If you need to pre-create stuff, then you won't need selinux-aware
> code in your apps. That's the approach we're taking.
> 
> Assuming this could be made to work (which I don't see how it can),
> I don't see why it's a good idea to force directory structure based on
> policy. Directories are made for grouping things, and security
> properties may or may not be the criterion you'd like to use
> for grouping. For example, the /tmp directory groups temporary files,
> which obviously need to be of different contexts - hence this entire
> problem.
> 

I think this is resolved - the directories need to be created ahead-of-time. 

There are many reasons to keep files from different domains from being created
in the same directory. The common example is the ability of two domains to
create files in the same directory allows them to pass information even if they
can't read each others files (through testing for the existence of files). Not a
concern on all systems, but a large concern on some.

Karl

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

> >  SELinux on Red Hat is suppose to be transparent and this clearly
> > is not.
> 
> This is strict policy only, not targeted.
> 
> >  If the rpm added the directories to user homedirs and labeled
> > them the net effect would be the same. I really question how this can be
> > thought of as anything other than an administrative issue. The admin
> > installs the app, the app needs it's resources labeled, the admin (by
> > way of rpm) should label the resources, I can't see how any other way
> > makes sense.
> 
> Okay, I agree with this solution. It's not very clear how to implement
> right now, but it is the right thing to do, eventually.
> 
> 
> 
> --
> 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.



--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 12:05 -0400, Joshua Brindle wrote:
> On Thu, 2005-06-09 at 22:32 -0400, Ivan Gyurdiev wrote:
> > > What problem is this solving?
> > 
> > It is solving the problem of labeling things properly in /tmp and /home
> > (according to recent policy changes,
> 
> relabeling at policy modification time is much better than automated
> relabeling when a user logs in

What do you mean? The policy is not modified when applications are 
installed. I know Tresys is working on binary policy modules, but 
at the current time policy is only modified when I upgrade
the selinux package, or when I recompile it.

> >  which I've been working on).
> > This cannot be accomplished by either inheriting the parent's context,
> > (because it's not the same), or by file_type_auto_trans, because of
> > ambiguity - same type change rule matches multiple target types.
> > You can see details of what I mean in the thread "file_type_auto_trans
> > is not sufficient" on selinux@tycho.nsa.gov.
> > 
> > It can be solved by setfscreate code in the application, but
> > that's worse - intrusive code in multiple applications.
> > 
> 
> it can also be solved by properly structuring directories, either by
> application configuration or if necessary modifying the application in a
> much less intrusive way (this was mentioned on that thread I believe)

I don't see how it's possible to solve this problem just by 
restructuring directories. Can you give an example of how
the gconf-vs-orbit problem can be solved - see the file_type_auto_trans
thread for full description.

> > Creating folders ahead of time is the most acceptable solution so far.
> > I'm not sure how exactly this should be done, but some sort of simple 
> > script like this is one possibility. 
> > 
> 
> scripts that install stuff to skel maybe should be responsible for
> adding them to user dirs and labeling properly. This would be a trusted
> app (rpm or whatever) instead of a user shell script

/skel does not work, because you have to apply the changes retroactively
to users that already exist. Additionally, tmp has to be handled
at startup time, because it can be on tmpfs.


--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 1:58 PM
> To: Joshua Brindle
> Cc: Daniel J Walsh; SELinux; selinux-dev@tresys.com
> Subject: Re: Restorecon script
> 
> On Fri, 2005-06-10 at 12:05 -0400, Joshua Brindle wrote:
> > On Thu, 2005-06-09 at 22:32 -0400, Ivan Gyurdiev wrote:
> > > > What problem is this solving?
> > >
> > > It is solving the problem of labeling things properly in /tmp and /home
> > > (according to recent policy changes,
> >
> > relabeling at policy modification time is much better than automated
> > relabeling when a user logs in
> 
> What do you mean? The policy is not modified when applications are
> installed. I know Tresys is working on binary policy modules, but
> at the current time policy is only modified when I upgrade
> the selinux package, or when I recompile it.
> 

Of course, but the concept holds that this only needs to be done when the rpm
that adds the need for the additional file types is installed. The fact that the
policy doesn't change until then is only an artifact of a lack of
infrastructure.

> > > It can be solved by setfscreate code in the application, but
> > > that's worse - intrusive code in multiple applications.
> > >
> >
> > it can also be solved by properly structuring directories, either by
> > application configuration or if necessary modifying the application in a
> > much less intrusive way (this was mentioned on that thread I believe)
> 
> I don't see how it's possible to solve this problem just by
> restructuring directories. Can you give an example of how
> the gconf-vs-orbit problem can be solved - see the file_type_auto_trans
> thread for full description.
> 

I thought this was answered - they need to be put in separate directories, e.g.
/tmp/orbit/orbit-$USER and /tmp/gconfd/gconfd-$USER. That way /tmp/orbit and
/tmp/gconfd can have different types and the only changes required for orbit and
gconfd are to put their files in a different location. If /tmp is tmpfs there
needs to be a script that creates these directories with the correct labels at
boot.

> > > Creating folders ahead of time is the most acceptable solution so far.
> > > I'm not sure how exactly this should be done, but some sort of simple
> > > script like this is one possibility.
> > >
> >
> > scripts that install stuff to skel maybe should be responsible for
> > adding them to user dirs and labeling properly. This would be a trusted
> > app (rpm or whatever) instead of a user shell script
> 
> /skel does not work, because you have to apply the changes retroactively
> to users that already exist. Additionally, tmp has to be handled
> at startup time, because it can be on tmpfs.

Changes retroactively seem problematic (see my other email). I think this is a
hard problem - not relabeling possibly means confused users and relabeling
possibly means going against the user's wishes or confusing them. I have to say
that not relabeling is probably more confusing, but it starts to feel like
fixing problems by rebooting . . . it just changes to logging in. 

Karl

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



--
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: Restorecon script

[Ivan Gyurdiev]

> > What do you mean? The policy is not modified when applications are
> > installed. I know Tresys is working on binary policy modules, but
> > at the current time policy is only modified when I upgrade
> > the selinux package, or when I recompile it.
> > 
> 
> Of course, but the concept holds that this only needs to be done when the rpm
> that adds the need for the additional file types is installed. The fact that the
> policy doesn't change until then is only an artifact of a lack of
> infrastructure.

/tmp on tmpfs is cleared on every boot, creating the need for
a startup script.

> > I don't see how it's possible to solve this problem just by
> > restructuring directories. Can you give an example of how
> > the gconf-vs-orbit problem can be solved - see the file_type_auto_trans
> > thread for full description.
> > 
> 
> I thought this was answered - they need to be put in separate directories, e.g.
> /tmp/orbit/orbit-$USER and /tmp/gconfd/gconfd-$USER. That way /tmp/orbit and
> /tmp/gconfd can have different types 

Who will create /tmp/orbit and /tmp/gconfd, and how will you
get them to have different types? 

> and the only changes required for orbit and
> gconfd are to put their files in a different location. If /tmp is tmpfs there
> needs to be a script that creates these directories with the correct labels at
> boot.

... and this leads us to... selinux.sh. 
Except you're saying that it should be executed once on boot, as root,
and not per login shell, is that correct? We may actually need to 
do that, since at the current time I can't create .ICE-unix in this
script - insufficient privileges.

> Changes retroactively seem problematic (see my other email). I think this is a
> hard problem - not relabeling possibly means confused users and relabeling
> possibly means going against the user's wishes or confusing them.

I don't think the user's intended to be changing the types of those 
directories - they are to be used for internal settings. That's
why most of them are hidden files.

>  I have to say
> that not relabeling is probably more confusing, but it starts to feel like
> fixing problems by rebooting . . . it just changes to logging in. 

The relabeling was actually not what I was focusing on - the
real issue was whether it's a good idea to pre-create folders
ahead of time.


--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 2:31 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; 'Daniel J Walsh'; 'SELinux'; selinux-dev@tresys.com
> Subject: RE: Restorecon script
> 
> 
> > and the only changes required for orbit and
> > gconfd are to put their files in a different location. If /tmp is tmpfs
> there
> > needs to be a script that creates these directories with the correct labels
> at
> > boot.
> 
> ... and this leads us to... selinux.sh.
> Except you're saying that it should be executed once on boot, as root,
> and not per login shell, is that correct? We may actually need to
> do that, since at the current time I can't create .ICE-unix in this
> script - insufficient privileges.
> 

Sort of - the script might need its own domain.

> > Changes retroactively seem problematic (see my other email). I think this is
> a
> > hard problem - not relabeling possibly means confused users and relabeling
> > possibly means going against the user's wishes or confusing them.
> 
> I don't think the user's intended to be changing the types of those
> directories - they are to be used for internal settings. That's
> why most of them are hidden files.
> 

Maybe - doesn't mean that blindly relabeling them won't cause problems or
confusion. It is a large change to reset permissions on home directories on
login. Seems like this is better done at installation time or on specific admin
/ user request.

> >  I have to say
> > that not relabeling is probably more confusing, but it starts to feel like
> > fixing problems by rebooting . . . it just changes to logging in.
> 
> The relabeling was actually not what I was focusing on - the
> real issue was whether it's a good idea to pre-create folders
> ahead of time.

Which it seems like it is in general.

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



--
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: Restorecon script

[Ivan Gyurdiev]

> Maybe - doesn't mean that blindly relabeling them won't cause problems or
> confusion. It is a large change to reset permissions on home directories on
> login. Seems like this is better done at installation time or on specific admin
> / user request.

Why should blindly relabeling internal files cause problems or 
confusion? I am assuming that policy has the correct context, and
anything else is wrong - after all those are _internal_ files,
not to be directly manipulated by the user, but handled
automatically.

The script does not reset permissions on home directories, it
resets permissions on specific subfolders. More importantly,
it does not reset the top level directory.


--
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: Restorecon script

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Friday, June 10, 2005 4:58 PM
> To: Karl MacMillan
> Cc: 'Joshua Brindle'; 'Daniel J Walsh'; 'SELinux'; selinux-dev@tresys.com
> Subject: RE: Restorecon script
> 
> 
> > Maybe - doesn't mean that blindly relabeling them won't cause problems or
> > confusion. It is a large change to reset permissions on home directories on
> > login. Seems like this is better done at installation time or on specific
> admin
> > / user request.
> 
> Why should blindly relabeling internal files cause problems or
> confusion? I am assuming that policy has the correct context, and
> anything else is wrong

Labeling by path is unsafe when the system is not in a known good state.

Karl

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

> - after all those are _internal_ files,
> not to be directly manipulated by the user, but handled
> automatically.
> 
> The script does not reset permissions on home directories, it
> resets permissions on specific subfolders. More importantly,
> it does not reset the top level directory.



--
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: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 02:31:23PM -0400, Ivan Gyurdiev wrote:
> 
> > > What do you mean? The policy is not modified when applications are
> > > installed. I know Tresys is working on binary policy modules, but
> > > at the current time policy is only modified when I upgrade
> > > the selinux package, or when I recompile it.
> > > 
> > 
> > Of course, but the concept holds that this only needs to be done when the rpm
> > that adds the need for the additional file types is installed. The fact that the
> > policy doesn't change until then is only an artifact of a lack of
> > infrastructure.
> 
> /tmp on tmpfs is cleared on every boot, creating the need for
> a startup script.
> 
> > > I don't see how it's possible to solve this problem just by
> > > restructuring directories. Can you give an example of how
> > > the gconf-vs-orbit problem can be solved - see the file_type_auto_trans
> > > thread for full description.
> > > 
> > 
> > I thought this was answered - they need to be put in separate directories, e.g.
> > /tmp/orbit/orbit-$USER and /tmp/gconfd/gconfd-$USER. That way /tmp/orbit and
> > /tmp/gconfd can have different types 
> 
> Who will create /tmp/orbit and /tmp/gconfd, and how will you
> get them to have different types? 
 
 a special selinux-aware library, that all gconfd-aware programs and
 orbit-aware programs must utilise, respectively.

 heck, it could even do the setfilecon() for you.

 l.


--
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: Restorecon script

[Ivan Gyurdiev]

> > Who will create /tmp/orbit and /tmp/gconfd, and how will you
> > get them to have different types? 
>  
>  a special selinux-aware library, that all gconfd-aware programs and
>  orbit-aware programs must utilise, respectively.
> 
>  heck, it could even do the setfilecon() for you.

That library is libselinux. I've already tried this,
and it doesn't work very well, for the reasons mentioned in my chown()
email.

==========

I do agree with the other comments, however, that a per application
solution is appropriate. For /tmp, we can we can implement a tmpskel
similar to /skel that gets created at init.

Please consider that this script was just yesterday's solution to make
the policy usable. I do realize that it has drawbacks, and does not
work well in the long run, so thanks for the comments.

The important thing to me is the agreement that creating folders
ahead of time is the right thing to do. The mechanism for doing
that can be changed.



--
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: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 05:57:48PM -0400, Ivan Gyurdiev wrote:
> 
> > > Who will create /tmp/orbit and /tmp/gconfd, and how will you
> > > get them to have different types? 
> >  
> >  a special selinux-aware library, that all gconfd-aware programs and
> >  orbit-aware programs must utilise, respectively.
> > 
> >  heck, it could even do the setfilecon() for you.
> 
> That library is libselinux. I've already tried this,
> and it doesn't work very well, for the reasons mentioned in my chown()
> email.
 
 sorry, i introduced two issues in my email: the one about chown() was
 just a thought tacked on to the end.

 please ignore and totally disassociate any thought about chown() from
 the "/tmp/<DIR>/.SOCKET-$USER" idea.

 
> ==========
> 
> I do agree with the other comments, however, that a per application
> solution is appropriate. 

 you mean a per-application-or-better-per-client-server group
 (gconfd is just the server...)

 which implies two functions: one for creating the socket in the right
 place (and the subdirectory if appropriate, hence there is a place
 where selinux could be introduced, if appropriate, to set the
 appropriate permissions: almost undoubtedly this will be needed).

 one for connection _to_ the socket.

> For /tmp, we can we can implement a tmpskel
> similar to /skel that gets created at init.

> Please consider that this script was just yesterday's solution to make
> the policy usable. I do realize that it has drawbacks, and does not
> work well in the long run, so thanks for the comments.
> 
> The important thing to me is the agreement that creating folders
> ahead of time is the right thing to do. The mechanism for doing
> that can be changed.
> 
> 

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
-

--
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: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 02:19:44PM -0400, Karl MacMillan wrote:

> > I don't see how it's possible to solve this problem just by
> > restructuring directories. Can you give an example of how
> > the gconf-vs-orbit problem can be solved - see the file_type_auto_trans
> > thread for full description.
> > 
> 
> I thought this was answered - they need to be put in separate directories, e.g.
> /tmp/orbit/orbit-$USER and /tmp/gconfd/gconfd-$USER. That way /tmp/orbit and
> /tmp/gconfd can have different types and the only changes required for orbit and
> gconfd are to put their files in a different location. If /tmp is tmpfs there
> needs to be a script that creates these directories with the correct labels at
> boot.

 and a solution to the "i can't do that because there are so many
 applications implicitly utilising /tmp/orbit-$USER, /tmp/gconfd-$USER,
 /tmp/.ICE-unix, /tmp/.font-unix, /tmp/.X11-unix, is to create a
 runtime-configurable library that can be told "use
 /tmp/<DIR>/.xxx-$USER instead of /tmp/.xxx-$USER".

 once all programs use the library, change the location.

 l.


--
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: Restorecon script

[Valdis.Kletnieks]

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

On Fri, 10 Jun 2005 21:21:26 BST, Luke Kenneth Casson Leighton said:

>  and a solution to the "i can't do that because there are so many
>  applications implicitly utilising /tmp/orbit-$USER, /tmp/gconfd-$USER,
>  /tmp/.ICE-unix, /tmp/.font-unix, /tmp/.X11-unix, is to create a
>  runtime-configurable library that can be told "use
>  /tmp/<DIR>/.xxx-$USER instead of /tmp/.xxx-$USER".
> 
>  once all programs use the library, change the location.

You'd *THINK* that a simple 'export TMPDIR=/tmp/$USER' would fix everything,
but NOOOOO.. ;)

(I wonder if Chad Seller's polyinstantation patches to build a small tree of
/tmp mounts per user, combined with fscontext= mounts, would do any good...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Restorecon script

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:

> You'd *THINK* that a simple 'export
> TMPDIR=/tmp/$USER' would fix everything,
> but NOOOOO.. ;)

The Unix MLS systems demonstrated that
this simple notion was a bit naive. Some
of the commonly used applications pre-date
environment variables (which came along
quite late in the evolution of Unix) and
have never really been happy with them.
Others intentionally eschew them for any
number of reasons that made sense at the
time.

I know, "in the Linux world, everything
get rewritten". Some habits appear to die
hard.

> (I wonder if Chad Seller's polyinstantation patches
> to build a small tree of
> /tmp mounts per user, combined with fscontext=
> mounts, would do any good...

If the experience of MLS on Unix is any guide
(I know that not everyone is convinced) then
yes, they will help in many cases. Most uses
of /tmp really don't care where files end up.
Alas, some do, and retraining everyone to do
it correctly has yet to take hold, even with
30 years of trying.

X11 puts it's UDS in /tmp to make running as
an unprivileged user easier. You could say that
a polyinstatiated /tmp does exactly the right
thing for X11. Unless you have a setuid
application. Or want to allow multiple users
or contexts to create windows.

On Unix MLS systems MLS X servers (there are
several) usually punt on the UDS issue 
(shared memory transports as well) and accept
only IP socket connections. But then, they use
labeled network protocols (CIPSO and/or TSIX)
to make that work right.

There does not appear to be a magic bullet
for this problem. PolyTmp helps, library
repairs can help, and fixing applications can
help. So long as the /tmp culture remains,
and there's no reason to expect it to die,
it will be a challenge to the humble
(and arrogant) system designer.

Oh, and the YahooMail spell checker wants to
replace "polyinstantiate" with "polyunsaturate".
In Trix we called 'em "moldy" directories, a
whimsical pronunciation of MLD. Must be Friday.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Restorecon script

[Stephen Smalley]

On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> Any comments on the following script?
> It's a profile script, to be shipped with selinux-policy-strict, 
> executed per login shell. It hardcodes the applications, 
> unfortunately, but does what we want for right now 
> (at least a temp. solution, unless someone has a better one?)
> Also, user needs to start a login shell to get it to run.

Under strict policy, restorecon fails upon the matchpathcon() call due
to lack of access to the file_contexts configuration.  The script
doesn't check for such failure, and thus ends up trying to run
restorecon repeatedly on "Permission" (Permission denied).

-- 
Stephen Smalley
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: Restorecon script

[Stephen Smalley]

On Fri, 2005-06-10 at 11:15 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> > Any comments on the following script?
> > It's a profile script, to be shipped with selinux-policy-strict, 
> > executed per login shell. It hardcodes the applications, 
> > unfortunately, but does what we want for right now 
> > (at least a temp. solution, unless someone has a better one?)
> > Also, user needs to start a login shell to get it to run.
> 
> Under strict policy, restorecon fails upon the matchpathcon() call due
> to lack of access to the file_contexts configuration.  The script
> doesn't check for such failure, and thus ends up trying to run
> restorecon repeatedly on "Permission" (Permission denied).

Looks like the user domains in strict policy would need r_dir_file() for
selinux_config_t, default_context_t, and file_context_t to be able to
run restorecon in their own domain.

-- 
Stephen Smalley
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 11:38 -0400, Stephen Smalley wrote:
> On Fri, 2005-06-10 at 11:15 -0400, Stephen Smalley wrote:
> > On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> > > Any comments on the following script?
> > > It's a profile script, to be shipped with selinux-policy-strict, 
> > > executed per login shell. It hardcodes the applications, 
> > > unfortunately, but does what we want for right now 
> > > (at least a temp. solution, unless someone has a better one?)
> > > Also, user needs to start a login shell to get it to run.
> > 
> > Under strict policy, restorecon fails upon the matchpathcon() call due
> > to lack of access to the file_contexts configuration.  The script
> > doesn't check for such failure, and thus ends up trying to run
> > restorecon repeatedly on "Permission" (Permission denied).
> 
> Looks like the user domains in strict policy would need r_dir_file() for
> selinux_config_t, default_context_t, and file_context_t to be able to
> run restorecon in their own domain.

yes, it also needs can_getsecurity... will fix.
There's also need for relabelto/relabelfrom on multiple domains.


--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 11:15 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> > Any comments on the following script?
> > It's a profile script, to be shipped with selinux-policy-strict, 
> > executed per login shell. It hardcodes the applications, 
> > unfortunately, but does what we want for right now 
> > (at least a temp. solution, unless someone has a better one?)
> > Also, user needs to start a login shell to get it to run.
> 
> Under strict policy, restorecon fails upon the matchpathcon() call due
> to lack of access to the file_contexts configuration.  The script
> doesn't check for such failure, and thus ends up trying to run
> restorecon repeatedly on "Permission" (Permission denied).

Yes, we're adding rules to make this work.
The current policy is rather broken, but I think we will have a version
that works (more or less) by the end of today.




--
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: Restorecon script

[Stephen Smalley]

On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> Any comments on the following script?
> It's a profile script, to be shipped with selinux-policy-strict, 
> executed per login shell. It hardcodes the applications, 
> unfortunately, but does what we want for right now 
> (at least a temp. solution, unless someone has a better one?)
> Also, user needs to start a login shell to get it to run.

There are a number of other directories under $HOME that likewise have
derived types, e.g.
$HOME/.ssh
$HOME/.gnupg
$HOME/.gconf
$HOME/.gconfd
$HOME/public_html

and some individual files like $HOME/.Xauthority.

-- 
Stephen Smalley
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 11:18 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-09 at 10:41 -0400, Ivan Gyurdiev wrote:
> > Any comments on the following script?
> > It's a profile script, to be shipped with selinux-policy-strict, 
> > executed per login shell. It hardcodes the applications, 
> > unfortunately, but does what we want for right now 
> > (at least a temp. solution, unless someone has a better one?)
> > Also, user needs to start a login shell to get it to run.
> 
> There are a number of other directories under $HOME that likewise have
> derived types, e.g.
> $HOME/.ssh
> $HOME/.gnupg
> $HOME/.gconf
> $HOME/.gconfd
> $HOME/public_html

file_type_auto_trans is sufficient to handle those at this time. 
We can add them one at a time, when transition conflicts arise.

> and some individual files like $HOME/.Xauthority.

Is .Xauthority created in a library, other than xauth?
It hasn't created any problems so far, so I've ignored it.

On the other hand, I know ICEauthority is created in libICE,
and that's currently broken, since I set its context to
ROLE_iceauth_home_t - for example gnome_session (one of
the two apps that appear to be relying on ICE), stores
files there, using libICE, and they're set to ROLE_home_t,
since that transition takes precedence. Perhaps the ICEauth
files should be moved to a subdirectory?



--
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: Restorecon script

[Luke Kenneth Casson Leighton]

On Fri, Jun 10, 2005 at 01:52:24PM -0400, Ivan Gyurdiev wrote:

> since that transition takes precedence. Perhaps the ICEauth
> files should be moved to a subdirectory?

 definitely.  however, as described in my other post just now,
 /tmp/.ICE-unix has "legacy" apps that need to be transitioned over
 to utilise a new directory.

 l.


--
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: Restorecon script

[Ivan Gyurdiev]

On Fri, 2005-06-10 at 21:23 +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 10, 2005 at 01:52:24PM -0400, Ivan Gyurdiev wrote:
> 
> > since that transition takes precedence. Perhaps the ICEauth
> > files should be moved to a subdirectory?
> 
>  definitely.  however, as described in my other post just now,
>  /tmp/.ICE-unix has "legacy" apps that need to be transitioned over
>  to utilise a new directory.

Do you know which applications exactly use ICE?
I've only seen gnome-session and dcop so far (and
then a lot of applications that talk to 
gnome-session/dcop over ICE)




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