mv and cp behavior.

mv and cp behavior.

[Daniel J Walsh]

Seems we have unexpected results when doing the mv command in both 
Strict and targeted policy.

A couple of examples where users are going to be confused (I was yesterday).

1. Setting up dhcp

     I was setting up a test dhcp server yesterday in targeted policy so
    I installed the machine,
    copied the dhcpd.conf file from an existing server to the /tmp
    directory.  Then I moved the file
    to the /etc/ directory.  I started the services and it blew up.  I
    ran audit2allow on the /var/log/messages
    file and got
    allow dhcpd_t tmp_t:file { read }
    At which point I went to the dhcp developer and asked him if dhcp
    had changed to require read access on /tmp.
    He said no, so I went back and looked at the log again and saw that
    it was trying to read dhcpd.conf as tmp_t.
    Now I understand what happened and ran restorecon on the file and
    everything worked fine.  The problem is
    that I have been using this stuff for a while and it confused me. 
    What is going to happen to our customers. 

2. Modifying files on a web server

    Collin has setup a web server and setup a directory underneath in
    /var/www/myblog it owned by httpd_staff_content_t which he
    can write files into and update his blog.  He edits files in his
    home directory can them moves them to the httpd directory.
    The problem is the apache server can't display them, because they
    have a context of staff_home_t.  (This would happen in both
    strict and targeted).    In this case he needs to use chcon to
    relabel the file to httpd_staff_content_t since restorecon would change
    the context to something else.

3.  Mv/cp do not follow the DAC conventions in all cases.  If I have a 
file marked as bin_t and executable and I move it to /tmp.
It is still executable in DAC but the bin_t context gets removed and 
replaced with some type of *_tmp_t context.

I believe that the what mv/cp is doing is wrong and we could do better, 
by default.

Seems we could do one or more of the following.

1.  Implement a matchpathcon in mv so the context is setup correctly on 
newly created files.  Users who can not do a matchpathcon
would fall back to current behavior.
    a.  This would fix the problem 1. dhcpd.conf would be marked 
dhcpd_conf_t
    b.  This would not work on problem 2. myblog.html would be marked 
httpd_sys_content_t
    c.  This would sometimes work for problem 3.  (IE if you move to a 
bin_t directory)
2.  When moving files to a new directory, adopt the context of the 
directories context rather them maintaining the current context.
    a.  This would not fix problem 1 (dhcpd.conf would be etc_t instead 
of dhcpd_etc_t)
    b.  This would work for problem 2. myblog.html would be 
httpd_staff_content_t
    c.  This would sometimes work for problem 3  (IE if you move to a 
bin_t directory)
3.  If the target file already exists mv -f would adopt the targets 
policy.  (cp already does this).
    a.  This would work on all three problems, but you still have the 
problem where the file does not exist.
4.  In certain situations file context is manipulated by policy.  IE if 
I move a file to /tmp, policy forces the file to be staff_tmp_t.

Suggestion on mv/cp behavior.  Combination of all above
1 If policy forces transition allow it to happen.  (IE if policy says 
staff users writing to /tmp must write staff_tmp_t than file ends up as 
staff_tmp_t)
2. If target file exists file after move has previous targets policy.
3. If target does not exist and mv can do a matchpathcon do it and set 
the context corretly.
4. If target does not exist and matchpathcon can not be done, adopt 
policy of target directory
5. If all above can't be done, use current behavior.

One problem with this is that other tools will act differently  IE 
rsync, ftp, scp ...

Ideas?

Dan



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: mv and cp behavior.

[Luke Kenneth Casson Leighton]

On Sat, Oct 16, 2004 at 10:23:43AM -0400, Daniel J Walsh wrote:

> I believe that the what mv/cp is doing is wrong and we could do better, 
> by default.
 
 after (funnily enough) just examining apache_macros.te, i don't see a
 file_auto_trans in there which i would have expected there to be.

 sure, there's a create_dir_file, but i would have expected at least to
 see some use of file_type_auto_trans($1_t, httpd_$1_content_t, httpd_$1_content_t)
 [i think that's right: if a user creates stuff in the
 httpd_user_content_t directory, it's given that same context]

 and yes i'd expect mv and cp to obey that file_type_auto_trans.

 l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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: mv and cp behavior.

[Stephen Smalley]

On Sat, 2004-10-16 at 10:23, Daniel J Walsh wrote:
> Seems we have unexpected results when doing the mv command in both 
> Strict and targeted policy.
> 
> A couple of examples where users are going to be confused (I was yesterday).
> 
> 1. Setting up dhcp
> 
>      I was setting up a test dhcp server yesterday in targeted policy so
>     I installed the machine,
>     copied the dhcpd.conf file from an existing server to the /tmp
>     directory.  Then I moved the file
>     to the /etc/ directory.

This is the same issue that came up on fedora-devel-list earlier.  mv
always preserves security context if possible (always for
intra-filesystem rename, and if the target filesystem supports it for
cross-filesystem rename).

> 2. Modifying files on a web server
> 
>     Collin has setup a web server and setup a directory underneath in
>     /var/www/myblog it owned by httpd_staff_content_t which he
>     can write files into and update his blog.  He edits files in his
>     home directory can them moves them to the httpd directory.
>     The problem is the apache server can't display them, because they
>     have a context of staff_home_t.  (This would happen in both
>     strict and targeted).    In this case he needs to use chcon to
>     relabel the file to httpd_staff_content_t since restorecon would change
>     the context to something else.

Only if he failed to update his file_contexts configuration to reflect
his setup for /var/www/myblog. 

> 3.  Mv/cp do not follow the DAC conventions in all cases.  If I have a 
> file marked as bin_t and executable and I move it to /tmp.
> It is still executable in DAC but the bin_t context gets removed and 
> replaced with some type of *_tmp_t context.

cp should only preserve security context when the --context/-c option is
used or when all attributes are supposed to be preserved, IIRC.  mv
should always preserve security context if possible (i.e. local
rename(2) or target filesystem supports the context).  If mv cannot
preserve security context, it should display a warning.  I think that
this behavior is consistent with DAC ownership/mode preservation.

> 1.  Implement a matchpathcon in mv so the context is setup correctly on 
> newly created files.

I had previously suggested changing mv to call matchpathcon on the new
path, compare with the existing context on the file, and _ask_ the user
if they want to relabel if they differ.  You don't want to do this
silently, as it subverts the protection.  Requires a user confirmation. 
Look at the existing mv code for dealing with overwriting an unwritable
file, where it also prompts the user for confirmation.

> 4.  In certain situations file context is manipulated by policy.  IE if 
> I move a file to /tmp, policy forces the file to be staff_tmp_t.

I don't follow; an explicit setfscreatecon() always overrides default
transitions.  But it may not be permitted by policy, in which case
you'll get a denial.

I don't recommend any change in behavior _other_ than having mv offer
the user the choice of relabeling.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: mv and cp behavior.

[Colin Walters]

On Mon, 2004-10-18 at 09:18 -0400, Stephen Smalley wrote:

> Only if he failed to update his file_contexts configuration to reflect
> his setup for /var/www/myblog. 

I raised this issue a while back.  I don't think it makes sense for me
to update file_contexts for /var/www/myblog because I am not acting as a
security administrator, although I do also have access to that role on
the machine.  I'm using SELinux's ability to let a normal staff_r user
relabel individual files as e.g. httpd_staff_script_exec_t.  The
security administrator should not have to be involved in maintaining
file_contexts for my discretionary control over my web content.

Fundamentally I still think that file_contexts should only be used to
initialize the system; thereafter xattrs should be canonical.  However,
if you recall I proposed an additional "user" xattr such as
"user.selinux.customized" that would be set explicitly by tools like
chcon so that an administrator could easily tell which labels had been
deliberately changed.  We'd then have an option like '-f' to
restorecon/setfiles to override that attribute, otherwise they would not
relabel the file. 

Alternatively perhaps setfiles/restorecon and the policy could become
aware of "type classes"; e.g. httpd_staff_content_t,
httpd_staff_script_ro_t, httpd_staff_script_exec_t would all be in the
same class, and thus would not be relabeled from one member of the class
to another by default by restorecon/setfiles.

> I had previously suggested changing mv to call matchpathcon on the new
> path, compare with the existing context on the file, and _ask_ the user
> if they want to relabel if they differ.  You don't want to do this
> silently, as it subverts the protection. 

Not all users have access necessary to invoke matchpathcon.  And I still
don't like using file_contexts for anything other than system
initialization.

> I don't recommend any change in behavior _other_ than having mv offer
> the user the choice of relabeling.

Dan and I talked about this for a bit today, and one problem he brought
up with mv doing prompting is that it has a large potential to break
scripts.  

For Dan's scenario 1), I just don't see any good solutions right now.
At least short of changing every script and program that invokes 'mv' to
do 'mv -f'.  I guess you could argue they're already buggy since mv can
potentially prompt in the DAC case too though...




--
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: mv and cp behavior.

[Stephen Smalley]

On Mon, 2004-10-18 at 12:07, Colin Walters wrote:
> I raised this issue a while back.  I don't think it makes sense for me
> to update file_contexts for /var/www/myblog because I am not acting as a
> security administrator, although I do also have access to that role on
> the machine.  I'm using SELinux's ability to let a normal staff_r user
> relabel individual files as e.g. httpd_staff_script_exec_t.  The
> security administrator should not have to be involved in maintaining
> file_contexts for my discretionary control over my web content.

Ok, but if you were able to use chcon to set the type in the first
place, then you presumably are able to use it after moving files there
in Dan's example scenario.

> Fundamentally I still think that file_contexts should only be used to
> initialize the system; thereafter xattrs should be canonical.  However,
> if you recall I proposed an additional "user" xattr such as
> "user.selinux.customized" that would be set explicitly by tools like
> chcon so that an administrator could easily tell which labels had been
> deliberately changed.  We'd then have an option like '-f' to
> restorecon/setfiles to override that attribute, otherwise they would not
> relabel the file. 

I still don't like using the user namespace for that purpose.  I'd
prefer an attribute in the security namespace, with corresponding DAC
and MAC checks applied to the ability to set it or remove it.

> Alternatively perhaps setfiles/restorecon and the policy could become
> aware of "type classes"; e.g. httpd_staff_content_t,
> httpd_staff_script_ro_t, httpd_staff_script_exec_t would all be in the
> same class, and thus would not be relabeled from one member of the class
> to another by default by restorecon/setfiles.

Yes, this seems to be a common suggestion; alternatives for file
contexts.

> Not all users have access necessary to invoke matchpathcon.  And I still
> don't like using file_contexts for anything other than system
> initialization.

True, under strict policy.  But the installed file_contexts
configuration is already being used for other purposes, e.g. rpm, udev,
restorecon invocations from scripts and rpm %post scriptlets.

> Dan and I talked about this for a bit today, and one problem he brought
> up with mv doing prompting is that it has a large potential to break
> scripts.  
> 
> For Dan's scenario 1), I just don't see any good solutions right now.
> At least short of changing every script and program that invokes 'mv' to
> do 'mv -f'.  I guess you could argue they're already buggy since mv can
> potentially prompt in the DAC case too though...

I suppose it would be interesting to see how many of these mv's are
crossing type boundaries anyway...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: mv and cp behavior.

[Colin Walters]

On Mon, 2004-10-18 at 13:14 -0400, Stephen Smalley wrote:

> Ok, but if you were able to use chcon to set the type in the first
> place, then you presumably are able to use it after moving files there
> in Dan's example scenario.

Right; this was just a related issue, not quite the same thing as Dan's
2).

> I still don't like using the user namespace for that purpose.  I'd
> prefer an attribute in the security namespace, with corresponding DAC
> and MAC checks applied to the ability to set it or remove it.

Ok, right.

> True, under strict policy.  But the installed file_contexts
> configuration is already being used for other purposes, e.g. rpm, udev,
> restorecon invocations from scripts and rpm %post scriptlets.

I think RPM counts as "system initialization".  udev is kind of a
special case.

> > Dan and I talked about this for a bit today, and one problem he brought
> > up with mv doing prompting is that it has a large potential to break
> > scripts.  
> > 
> > For Dan's scenario 1), I just don't see any good solutions right now.
> > At least short of changing every script and program that invokes 'mv' to
> > do 'mv -f'.  I guess you could argue they're already buggy since mv can
> > potentially prompt in the DAC case too though...
> 
> I suppose it would be interesting to see how many of these mv's are
> crossing type boundaries anyway...

Yeah.  I'm kind of curious why Dan wrote the dhcp.conf in /tmp and later
moved it to /etc; I'd imagine most admins would just
$EDITOR /etc/dhcp.conf.

Anyways, for FC3 I think we are not going to be able to do a prompting
mv.  However I'd be interested in turning on mv prompting in FC4, and
seeing how much from the collection of shell scripts on the system
actually breaks.


--
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: mv and cp behavior.

[Erich Schubert]

Hi,
btw: an easy way of doing a "cp" without changing destination file
properties (unix and selinux) is using "cat sourcefile > destfile"

Sure, this is not the most efficient, but for example on text files it
really doesn't matter.

Greetings,
Erich Schubert
-- 
     erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C     (o_
 A man doesn't know what he knows until he knows what he doesn't know. //\
         Es gibt kein idiotensicheres Programm, weil Idioten so        V_/_
                       genial sind. -- E. Murphy


--
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: mv and cp behavior.

[Colin Walters]

On Mon, 2004-10-18 at 20:22 +0200, Erich Schubert wrote:
> Hi,
> btw: an easy way of doing a "cp" without changing destination file
> properties (unix and selinux) is using "cat sourcefile > destfile"

This is actually what cp does now if the file already exists.



--
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: mv and cp behavior.

[Nifty Hat Mitch]

On Mon, Oct 18, 2004 at 01:43:56PM -0400, Colin Walters wrote:
> On Mon, 2004-10-18 at 13:14 -0400, Stephen Smalley wrote:
> 
> > Ok, but if you were able to use chcon to set the type in the first
> > place, then you presumably are able to use it after moving files there
> > in Dan's example scenario.
> 
> Right; this was just a related issue, not quite the same thing as Dan's
....
> Yeah.  I'm kind of curious why Dan wrote the dhcp.conf in /tmp and later
> moved it to /etc; I'd imagine most admins would just
> $EDITOR /etc/dhcp.conf.

I am not sure why Dan would but, in a large site administration context
I might expect that that "$EDITOR /etc/dhcp.conf" is not permitted.
Some places want to have testing, approval and change log policy.

Something like these untested lines.
  scp approved-new-dhcp.conf  user@keyhost:~/approved-new-dhcp.conf
  ssh user@keyhost sudo mv /etc/dhcp.conf /etc/dhcp.conf.save`date +%s`
  ssh user@keyhost sudo mv ~/approved-new-dhcp.conf /etc/dhcp.conf
  ssh user@keyhost sudo service dhcpd reload

Anyhow some staged approval process with an audit trail....



-- 
	T o m  M i t c h e l l 
	May your cup runneth over with goodness and mercy
	and may your buffers never overflow.

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