how to cope with file renames?

how to cope with file renames?

[Michal Svoboda]

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

Hello,

I'm struggling with the problem seemingly as old as filesystems - if you
rename() a file, it retains all its permissions, incl. the context,
because its inode stays the same.

My particular problem is moving stuff from /tmp using PHP's
move_uploaded_file function. I'm aware of the copy/delete workaround,
but that just isn't the same (performance, atomicity, etc.) Also there
is the way of post-relabeling the moved file but that requires more
permissions plus there are no selinux bindings in PHP that i'm aware of.

In short, I was wondering if there was a way for a rename()d file to be
subjected to a type transition as if a new file was created? (I tried a
type_trans rule but to no avail.) Or any other way to deal with renaming
files between variously contexted dirs?

Michal Svoboda


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

Re: how to cope with file renames?

[Daniel J Walsh]

On 03/11/2010 03:19 AM, Michal Svoboda wrote:
> Hello,
>
> I'm struggling with the problem seemingly as old as filesystems - if you
> rename() a file, it retains all its permissions, incl. the context,
> because its inode stays the same.
>
> My particular problem is moving stuff from /tmp using PHP's
> move_uploaded_file function. I'm aware of the copy/delete workaround,
> but that just isn't the same (performance, atomicity, etc.) Also there
> is the way of post-relabeling the moved file but that requires more
> permissions plus there are no selinux bindings in PHP that i'm aware of.
>
>    
I think this is your best option.  Or write your own version.  Maybe 
open a bugzilla on coreutils asking for
an option to either allow you to state the file context of the 
destination or just do not preserve file context.

> In short, I was wondering if there was a way for a rename()d file to be
> subjected to a type transition as if a new file was created? (I tried a
> type_trans rule but to no avail.) Or any other way to deal with renaming
> files between variously contexted dirs?
>
> Michal Svoboda
>
>    


--
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: how to cope with file renames?

[Stephen Smalley]

On Thu, 2010-03-11 at 09:19 +0100, Michal Svoboda wrote:
> Hello,
> 
> I'm struggling with the problem seemingly as old as filesystems - if you
> rename() a file, it retains all its permissions, incl. the context,
> because its inode stays the same.
> 
> My particular problem is moving stuff from /tmp using PHP's
> move_uploaded_file function. I'm aware of the copy/delete workaround,
> but that just isn't the same (performance, atomicity, etc.) Also there
> is the way of post-relabeling the moved file but that requires more
> permissions plus there are no selinux bindings in PHP that i'm aware of.

http://pecl.php.net/package/selinux

> In short, I was wondering if there was a way for a rename()d file to be
> subjected to a type transition as if a new file was created? (I tried a
> type_trans rule but to no avail.) Or any other way to deal with renaming
> files between variously contexted dirs?

No.  The best way of course is to create the file with the right
security context in the first place, whether explicitly or by uploading
it to the same parent directory as the final destination.  Alternatively
the php scriptlet can use the selinux bindings to manipulate the
context, or you can configure restorecond(8) to watch for the
destination file and reset its security context as needed.

-- 
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: how to cope with file renames?

[Richard Bullington-McGuire]

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

On Thu, Mar 11, 2010 at 8:46 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

>
> http://pecl.php.net/package/selinux
>
>
It's funny that you mention pecl in this context, since pecl itself has the
same behavior that the original poster mentioned with regard to  SELinux, at
least on RHEL 5. When you install a module using pecl, it compiles it in a
temporary directory and them moves it into place in the PHP library
directory. The resulting module has the SELinux label from the temporary
directory, user_u:object_r:tmp_t, not the system_u:object_r:textrel_shlib_t
label that the other PHP modules in the /usr/lib64/php/modules directory
have. Issuing a quick 'restorecon' command versus the resulting php module
file adjusted its context so that httpd could read it.

-- 
Richard Bullington-McGuire | Director of Technology | Three Pillar Global
mobile: 571.236.0938 | fax: 703-564-5595 | PGP key ID:  0xDAC3028E
richard.bullington-mcguire@threepillarglobal.com | www.threepillarglobal.com

[-- Attachment #2: Type: text/html, Size: 1524 bytes --]

Re: how to cope with file renames?

[Michal Svoboda]

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

Stephen Smalley wrote:
> http://pecl.php.net/package/selinux

Thanks!

> > In short, I was wondering if there was a way for a rename()d file to be
> > subjected to a type transition as if a new file was created? (I tried a
> > type_trans rule but to no avail.) Or any other way to deal with renaming
> > files between variously contexted dirs?
> 
> No.  The best way of course is to create the file with the right
> security context in the first place, whether explicitly or by uploading
> it to the same parent directory as the final destination.

That's what I do right now. I can do that because there's only one
context. But in a web service your script isn't invoked until the file
is already uploaded. So you can't pre-set the correct context and/or
destination if you have two or more possibilities.

> Alternatively the php scriptlet can use the selinux bindings to
> manipulate the context, or you can configure restorecond(8) to watch
> for the destination file and reset its security context as needed.

Does restorecond handle recursive directory restoring yet? (Last time I
tried it worked only on single files.)

But yes, in principle a cron job with 'restorecon -R' is a way too. But
all those solutions are 'dirty', because they need you to make an extra
effort. There's already a huge infrastructure with type inheritance and
transitions, as to make the labeling independent of the application; but
the rename operation just spoils that and forces you back to square one, 
to explicitly care about your files' contexts. Is there a fundamental
reason why this is so (and can't be changed)?


Michal Svoboda

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

Re: how to cope with file renames?

[Stephen Smalley]

On Thu, 2010-03-11 at 18:00 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > http://pecl.php.net/package/selinux
> 
> Thanks!
> 
> > > In short, I was wondering if there was a way for a rename()d file to be
> > > subjected to a type transition as if a new file was created? (I tried a
> > > type_trans rule but to no avail.) Or any other way to deal with renaming
> > > files between variously contexted dirs?
> > 
> > No.  The best way of course is to create the file with the right
> > security context in the first place, whether explicitly or by uploading
> > it to the same parent directory as the final destination.
> 
> That's what I do right now. I can do that because there's only one
> context. But in a web service your script isn't invoked until the file
> is already uploaded. So you can't pre-set the correct context and/or
> destination if you have two or more possibilities.
> 
> > Alternatively the php scriptlet can use the selinux bindings to
> > manipulate the context, or you can configure restorecond(8) to watch
> > for the destination file and reset its security context as needed.
> 
> Does restorecond handle recursive directory restoring yet? (Last time I
> tried it worked only on single files.)
> 
> But yes, in principle a cron job with 'restorecon -R' is a way too. But
> all those solutions are 'dirty', because they need you to make an extra
> effort. There's already a huge infrastructure with type inheritance and
> transitions, as to make the labeling independent of the application; but
> the rename operation just spoils that and forces you back to square one, 
> to explicitly care about your files' contexts. Is there a fundamental
> reason why this is so (and can't be changed)?

SELinux isn't name-based.  rename() doesn't change your file mode or
ACLs either.

-- 
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: how to cope with file renames?

[Daniel J Walsh]

On 03/11/2010 12:00 PM, Michal Svoboda wrote:
> Stephen Smalley wrote:
>    
>> http://pecl.php.net/package/selinux
>>      
> Thanks!
>
>    
>>> In short, I was wondering if there was a way for a rename()d file to be
>>> subjected to a type transition as if a new file was created? (I tried a
>>> type_trans rule but to no avail.) Or any other way to deal with renaming
>>> files between variously contexted dirs?
>>>        
>> No.  The best way of course is to create the file with the right
>> security context in the first place, whether explicitly or by uploading
>> it to the same parent directory as the final destination.
>>      
> That's what I do right now. I can do that because there's only one
> context. But in a web service your script isn't invoked until the file
> is already uploaded. So you can't pre-set the correct context and/or
> destination if you have two or more possibilities.
>
>    
>> Alternatively the php scriptlet can use the selinux bindings to
>> manipulate the context, or you can configure restorecond(8) to watch
>> for the destination file and reset its security context as needed.
>>      
> Does restorecond handle recursive directory restoring yet? (Last time I
> tried it worked only on single files.)
>
> But yes, in principle a cron job with 'restorecon -R' is a way too. But
> all those solutions are 'dirty', because they need you to make an extra
> effort. There's already a huge infrastructure with type inheritance and
> transitions, as to make the labeling independent of the application; but
> the rename operation just spoils that and forces you back to square one,
> to explicitly care about your files' contexts. Is there a fundamental
> reason why this is so (and can't be changed)?
>
>
> Michal Svoboda
>    
restorecond can handle * But not recursive.

You can watch ~/* for all entries in the homedir.  It would not be hard 
to add a watch an entire tree.

Just need to walk the tree adding watches for ever directory and any 
time a a new directory shows up you would add it to the watch list.  I 
am not sure how much inotify can handle.  We might get in trouble with 
the amount of resoures used.

~/...

Could watch millions of directories.


--
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: how to cope with file renames?

[Michal Svoboda]

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

Stephen Smalley wrote:
> SELinux isn't name-based. 

This is not so much about names but about relationship to the parent
container. I don't care if the file is called foo or bar, but if its
parent dir has foo_t or bar_t context. There already is some coupling
between the file and its directory. For example, to actually do the
rename you need file as well as directory permissions.

So in that regard, why an additional type transition in that operation
would be harmful?

> rename() doesn't change your file mode or ACLs either.

Yes, that's why I said it's an old problem. I hoped that someone would
have solved it in a systemic way.


Daniel J Walsh wrote:
> Just need to walk the tree adding watches for ever directory and any
> time a a new directory shows up you would add it to the watch list.
> I am not sure how much inotify can handle.  We might get in trouble
> with the amount of resoures used.

See the -r in man inotifywait (http://linux.die.net/man/1/inotifywait).
Actually you can use that tool and restorecon in a simple shell script
to make a restorecond of your own. But having this in hand, you don't
need neither inheritance nor type transitions for files. You could just
make any new file with default_t and wait until restorecon labels it.


Michal Svoboda

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

Re: how to cope with file renames?

[Stephen Smalley]

On Thu, 2010-03-11 at 19:28 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > SELinux isn't name-based. 
> 
> This is not so much about names but about relationship to the parent
> container. I don't care if the file is called foo or bar, but if its
> parent dir has foo_t or bar_t context. There already is some coupling
> between the file and its directory. For example, to actually do the
> rename you need file as well as directory permissions.
> 
> So in that regard, why an additional type transition in that operation
> would be harmful?

Type transitions take place when new subjects or objects are created,
not during their existence.  What you want is relabeling /
non-tranquility, and that is something to be minimized, carefully
controlled, and explicitly identified in the system, not an implicit
side effect of another operation.

> > rename() doesn't change your file mode or ACLs either.
> 
> Yes, that's why I said it's an old problem. I hoped that someone would
> have solved it in a systemic way.

Some of us view it as correct behavior, not as a problem.  In any event,
"solving it" in the kernel would require cooperation from the filesystem
code in order to provide an atomic rename+setxattr operation, just as we
required filesystem cooperation to provide an atomic create+setxattr
operation.  So it goes well beyond the scope of the SELinux code.

> 
> Daniel J Walsh wrote:
> > Just need to walk the tree adding watches for ever directory and any
> > time a a new directory shows up you would add it to the watch list.
> > I am not sure how much inotify can handle.  We might get in trouble
> > with the amount of resoures used.
> 
> See the -r in man inotifywait (http://linux.die.net/man/1/inotifywait).
> Actually you can use that tool and restorecon in a simple shell script
> to make a restorecond of your own. But having this in hand, you don't
> need neither inheritance nor type transitions for files. You could just
> make any new file with default_t and wait until restorecon labels it.

The Warning section on that option is a bit worrisome.

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