Accessibility of swap files

Accessibility of swap files

[mp.lists]

Hi *,

I think, measures can|should be taken, which reduce the probability of having a
swap file inadvertently run with too open permissions.

As a first idea, it looks, as if such may be implemented, eg. by
     letting swapon [and fstab-based "mounting"] by default not enable a swap
file, if it has non-root access permissions
  || letting mkswap by default ignore too open settings of umask and create the
swap file mod 0600 instead
.
In both cases, an explicit switch|parameter could enable the present,
non-restrictive behaviour.


Best regards,

   Markus


PS: I'm speaking as of util-linux-ng version 2.17.2.

Re: Accessibility of swap files

[Bernhard Voelker]

On November 6, 2012 at 4:06 PM mp.lists@free.fr wrote:
> Hi *,
>
> I think, measures can|should be taken, which reduce the probability of having
> a
> swap file inadvertently run with too open permissions.
>
> As a first idea, it looks, as if such may be implemented, eg. by
>      letting swapon [and fstab-based "mounting"] by default not enable a swap
> file, if it has non-root access permissions

Did you know?
The swapon utility issues a warning diagnostic with --verbose:

  # ls -l /tmp/swapfile
  -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile

  # sbin/swapon -v  /tmp/swapfile
  swapon /tmp/swapfile
  swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
  swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
  swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same byte
order
  swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728, devsize=134217728

BTW: the check for the owner has been added in 2.19
(in commit v2.18-88-g306c1df).

I don't know if refusing to swapon insecure swap files is a good
idea (see below).

>   || letting mkswap by default ignore too open settings of umask and create
> the
> swap file mod 0600 instead.

You don't need root privs to run mkswap. Furthermore, mkswap
doesn't create the swap file (in terms of calling creat()).
Instead, it just writes to it.
Nevertheless, I think a warning would be enough/nice at this stage.

> In both cases, an explicit switch|parameter could enable the present,
> non-restrictive behaviour.

Changing behavior is not always a good idea for compatibility reasons,
and therefore deserves *good* arguments.
Let Karel decide.

> PS: I'm speaking as of util-linux-ng version 2.17.2.

I'm speaking about the latest version in Git. ;-)

Have a nice day,
Berny

Re: Accessibility of swap files

[Karel Zak]

On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
> On November 6, 2012 at 4:06 PM mp.lists@free.fr wrote:
> > Hi *,
> >
> > I think, measures can|should be taken, which reduce the probability of having
> > a
> > swap file inadvertently run with too open permissions.

 well, you need root permissions to use swapon, the swap devices and
 files are defined in /etc/fstan which is writable by root only.

 I have doubts that we have to make the system so paranoid and
 resistant to admin's bugs. And if you really need this level of
 paranoia then use SELinux (or so) rather than expect hardcoded rules
 in swapon(8).

> > As a first idea, it looks, as if such may be implemented, eg. by
> >      letting swapon [and fstab-based "mounting"] by default not enable a swap
> > file, if it has non-root access permissions
> 
> Did you know?
> The swapon utility issues a warning diagnostic with --verbose:
> 
>   # ls -l /tmp/swapfile
>   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
> 
>   # sbin/swapon -v  /tmp/swapfile
>   swapon /tmp/swapfile
>   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
>   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
>   swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same byte
> order
>   swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728, devsize=134217728

 this waring is there since year 1999.. so it's really nothing new.

> BTW: the check for the owner has been added in 2.19
> (in commit v2.18-88-g306c1df).
> 
> I don't know if refusing to swapon insecure swap files is a good
> idea (see below).
> 
> >   || letting mkswap by default ignore too open settings of umask and create
> > the
> > swap file mod 0600 instead.

 sorry, this is nonsense

> You don't need root privs to run mkswap. Furthermore, mkswap
> doesn't create the swap file (in terms of calling creat()).

 yep, you can use cp(1) or dd(1) to create the file as a copy...

> Instead, it just writes to it.
> Nevertheless, I think a warning would be enough/nice at this stage.
> 
> > In both cases, an explicit switch|parameter could enable the present,
> > non-restrictive behaviour.
> 
> Changing behavior is not always a good idea for compatibility reasons,
> and therefore deserves *good* arguments.

Yes, I don't see good arguments.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Accessibility of swap files

[Sami Kerola]

On Wed, Nov 21, 2012 at 10:08 AM, Karel Zak <kzak@redhat.com> wrote:
> On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
>> On November 6, 2012 at 4:06 PM mp.lists@free.fr wrote:
>> > As a first idea, it looks, as if such may be implemented, eg. by
>> >      letting swapon [and fstab-based "mounting"] by default not enable a swap
>> > file, if it has non-root access permissions
>>
>> Did you know?
>> The swapon utility issues a warning diagnostic with --verbose:
>>
>>   # ls -l /tmp/swapfile
>>   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
>>
>>   # sbin/swapon -v  /tmp/swapfile
>>   swapon /tmp/swapfile
>>   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
>>   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
>>   swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same byte
>> order
>>   swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728, devsize=134217728
>
>  this waring is there since year 1999.. so it's really nothing new.

I wonder would be be too noisy to make insecurity warnings enabled by
default,  and add --quiet option to thous who do not want to hear
system complaining about things they know.

Re: Accessibility of swap files

[Karel Zak]

On Wed, Nov 21, 2012 at 01:46:59PM +0000, Sami Kerola wrote:
> On Wed, Nov 21, 2012 at 10:08 AM, Karel Zak <kzak@redhat.com> wrote:
> > On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
> >> On November 6, 2012 at 4:06 PM mp.lists@free.fr wrote:
> >> > As a first idea, it looks, as if such may be implemented, eg. by
> >> >      letting swapon [and fstab-based "mounting"] by default not enable a swap
> >> > file, if it has non-root access permissions
> >>
> >> Did you know?
> >> The swapon utility issues a warning diagnostic with --verbose:
> >>
> >>   # ls -l /tmp/swapfile
> >>   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
> >>
> >>   # sbin/swapon -v  /tmp/swapfile
> >>   swapon /tmp/swapfile
> >>   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
> >>   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
> >>   swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same byte
> >> order
> >>   swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728, devsize=134217728
> >
> >  this waring is there since year 1999.. so it's really nothing new.
> 
> I wonder would be be too noisy to make insecurity warnings enabled by
> default,  and add --quiet option to thous who do not want to hear
> system complaining about things they know.
> 

 since util-linux 2.9t:

    /* people generally dislike this warning - now it is printed
       only when `verbose' is set */

 :-)



-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Accessibility of swap files

[Karel Zak]

On Fri, Dec 07, 2012 at 08:14:34PM +0100, mp.lists@free.fr wrote:
> > > Did you know?
> > > The swapon utility issues a warning diagnostic with --verbose:
> > >
> > >   # ls -l /tmp/swapfile
> > >   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
> > >
> > >   # sbin/swapon -v  /tmp/swapfile
> > >   swapon /tmp/swapfile
> > >   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
> > >   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.

 I have improved swapon(8), so the --verbose option is not necessary,
 the warnings about insecure perms/owner is always printed.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Accessibility of swap files

[mp.lists]

Karel Zak <kzak@...> writes:

>
> On Wed, Nov 21, 2012 at 01:46:59PM +0000, Sami Kerola wrote:
> > On Wed, Nov 21, 2012 at 10:08 AM, Karel Zak <kzak@...> wrote:
> > > On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
> > >> On November 6, 2012 at 4:06 PM mp.lists@... wrote:
> > >> > As a first idea, it looks, as if such may be implemented, eg. by
> > >> >      letting swapon [and fstab-based "mounting"] by default not enable
a swap
> > >> > file, if it has non-root access permissions
> > >>
> > >> Did you know?
> > >> The swapon utility issues a warning diagnostic with --verbose:
> > >>
> > >>   # ls -l /tmp/swapfile
> > >>   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
> > >>
> > >>   # sbin/swapon -v  /tmp/swapfile
> > >>   swapon /tmp/swapfile
> > >>   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
> > >>   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
> > >>   swapon: /tmp/swapfile: found swap signature: version 1, page-size 4,
same byte
> > >> order
> > >>   swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728,
devsize=134217728
> > >
> > >  this waring is there since year 1999.. so it's really nothing new.
> >
Fine.

This contains three kinds of information:
  - a line, which is redundant wrt the command line
  - two lines of {critical, in my opinion} warning about insecure fs permissions
  - another two lines, which characterise the content of the swapfile


...
>
>  since util-linux 2.9t:
>
>     /* people generally dislike this warning - now it is printed
>        only when `verbose' is set */
>
Does anybody have a pointer to the arguments, why people dislike to know
about insecure permissions?!

Since I can rarely imagine any useful use case of insecure swap file
permissions compared to the immense security hole, an open swap file usually
presents, I would propose to:
  - remove the first line, which is redundant to the command line
    {low prio; you may leave it in order not to break anything}
  -    write the two lines of critical warning [as cited above] also,
       if --verbose isn't set
       {at least}
    || refuse to swapon|mount a swap file with insecure permissions without
       a "--force" parameter {also in fstab}
       {preferrable}


To make my arguments more understandable on the social level:
it's a quite frequent use case, that some root is given the task to work on a
POSIX system, he does not have any deeper knowledge of, yet.  May be, it's a
fresh Unix installation or a VM image.  At least in my experience, it's a
relatively early activity in the life-cycle of a system to adjust a its swap
configuration.  root has a hard time, if he has to work in a complex
environment[, where is he is almost always in a situation, he does not know
enough about,] without compromising hese systems, when he can not rely on a
paranoid policy of those, who prepared his ground.


I hope, this makes my intention understandable, and lets reconsider their
good-enough-ness.


Best, Markus

Re: Accessibility of swap files

[mp.lists]

Karel Zak <kzak@...> writes:

>
> On Tue, Nov 06, 2012 at 05:25:02PM +0100, Bernhard Voelker wrote:
> > On November 6, 2012 at 4:06 PM mp.lists@... wrote:
> > > Hi *,
> > >
> > > I think, measures can|should be taken, which reduce the probability of
having
> > > a
> > > swap file inadvertently run with too open permissions.
>
>  well, you need root permissions to use swapon, the swap devices and
>  files are defined in /etc/fstan which is writable by root only.
>
Very often "root" is a human.


>  I have doubts that we have to make the system so paranoid and
>  resistant to admin's bugs. And if you really need this level of
>  paranoia then use SELinux (or so) rather than expect hardcoded rules
>  in swapon(8).
>
Let me say it more liberally:
I expect a POSIXoid system in its default status to be configured the paranoid
way.  Everything else shall be an explicit informed decision.

I don't care, how paranoia is implemented, but it has to be omnipresent to a
reasonable degree.  If not, we may [in the best case] achieve correctness in a
mathematical sense, but never practically.


> > > As a first idea, it looks, as if such may be implemented, eg. by
> > >      letting swapon [and fstab-based "mounting"] by default not enable a
swap
> > > file, if it has non-root access permissions
> >
> > Did you know?
> > The swapon utility issues a warning diagnostic with --verbose:
> >
> >   # ls -l /tmp/swapfile
> >   -rw-r--r-- 1 berny users 134217728 Nov  6 17:03 /tmp/swapfile
> >
> >   # sbin/swapon -v  /tmp/swapfile
> >   swapon /tmp/swapfile
> >   swapon: /tmp/swapfile: insecure permissions 0644, 0600 suggested.
> >   swapon: /tmp/swapfile: insecure file owner 1000, 0 (root) suggested.
> >   swapon: /tmp/swapfile: found swap signature: version 1, page-size 4, same
byte
> > order
> >   swapon: /tmp/swapfile: pagesize=4096, swapsize=134217728,
devsize=134217728
>
>  this waring is there since year 1999.. so it's really nothing new.
>
> > BTW: the check for the owner has been added in 2.19
> > (in commit v2.18-88-g306c1df).
> >
> > I don't know if refusing to swapon insecure swap files is a good
> > idea (see below).
> >
> > >   || letting mkswap by default ignore too open settings of umask and
create
> > > the
> > > swap file mod 0600 instead.
>
>  sorry, this is nonsense
>
You are right.


> > You don't need root privs to run mkswap. Furthermore, mkswap
> > doesn't create the swap file (in terms of calling creat()).
>
>  yep, you can use cp(1) or dd(1) to create the file as a copy...
>
> > Instead, it just writes to it.
> > Nevertheless, I think a warning would be enough/nice at this stage.
> >
> > > In both cases, an explicit switch|parameter could enable the present,
> > > non-restrictive behaviour.
> >
> > Changing behavior is not always a good idea for compatibility reasons,
> > and therefore deserves *good* arguments.
>
> Yes, I don't see good arguments.
>
See my next posting.

{In order to get the right balance, I think, its a good idea to have a look at
those well-known systems, which are built on the policy of compatibility... }


Best, Markus