noexec mount-option with selinux?

[Marten Lehmann]

Hello,

I would like to mount the /tmp directory with the noexec option, so that no
files can be executed directly from /tmp. But the problem is, that I don't
have a separate partition for /tmp. It would be useless to create one, because
the users on this system have strict quota limits, which wouldn't apply on a
separate /tmp partition.

Lots of example policies only show ways to restrict certain applications. But
is there a way to restrict access to the /tmp directory in general, too?

Regards
Marten

[Stephen Smalley]

On Wed, 2006-05-10 at 11:13 +0200, Marten Lehmann wrote:
>  Hello,
>  
>  I would like to mount the /tmp directory with the noexec option, so that no
>  files can be executed directly from /tmp. But the problem is, that I don't
>  have a separate partition for /tmp. It would be useless to create one, because
>  the users on this system have strict quota limits, which wouldn't apply on a
>  separate /tmp partition.
>  
>  Lots of example policies only show ways to restrict certain applications. But
>  is there a way to restrict access to the /tmp directory in general, too? 
You can certainly not allow execute permission to *_tmp_t (the types
applied to files created in /tmp) in your policy.  In fact, most domains
should already be that way.  unconfined_t naturally can do that (since
it is unconfined); you could create a customized version of it that
isn't allowed to do that, but only via a custom policy.

-- 
Stephen Smalley
National Security Agency

[David Caplan]

On Wed, 2006-05-10 at 07:29 -0400, Stephen Smalley wrote:
>  On Wed, 2006-05-10 at 11:13 +0200, Marten Lehmann wrote:
>  > Hello,
>  > 
>  > I would like to mount the /tmp directory with the noexec option, so that no
>  > files can be executed directly from /tmp. But the problem is, that I don't
>  > have a separate partition for /tmp. It would be useless to create one, because
>  > the users on this system have strict quota limits, which wouldn't apply on a
>  > separate /tmp partition.
>  > 
>  > Lots of example policies only show ways to restrict certain applications. But
>  > is there a way to restrict access to the /tmp directory in general, too?
>  
>  You can certainly not allow execute permission to *_tmp_t (the types
>  applied to files created in /tmp) in your policy.  In fact, most domains
>  should already be that way.  unconfined_t naturally can do that (since
>  it is unconfined); you could create a customized version of it that
>  isn't allowed to do that, but only via a custom policy.
>   
Keep in mind that not every file created in /tmp gets a *_tmp_t type.
(sesearch --type -t tmp_t policy.conf)

I think this ("not allow execute permission to *_tmp_t") may be harder
than you think unless you want to restrict a single domain type.  On my
FC5 machine (with a default policy) I see almost 30 domains with execute
access on various tmp file types:
sesearch --allow -t tmp -i -p execute -c file 

I see over 30 in a strict version of the reference policy. I don't know
if the execute access is necessary, but I suspect a lot of things will
break if the access is removed.

David

(Note sesearch is part of the setools package and gives you some of the
policy searching capabilities of apol on the command line.)

[Stephen Smalley]

On Wed, 2006-05-10 at 07:54 -0400, david caplan wrote:
>  Keep in mind that not every file created in /tmp gets a *_tmp_t
> type.
>  (sesearch --type -t tmp_t policy.conf) 
On FC5, default policy, the only types I get from that output (applied
to the installed binary policy, as there is no policy.conf) that don't
include a _tmp_t suffix are httpd_sys_script_rw_t (for files created
under /tmp by CGIs) and cardmgr_dev_t (for device nodes created by
cardmgr).  Offhand, I don't see why those should be executable either.

>  I think this ("not allow execute permission to *_tmp_t")
> may be harder
>  than you think unless you want to restrict a single domain type.  On my
>  FC5 machine (with a default policy) I see almost 30 domains with execute
>  access on various tmp file types:
>  sesearch --allow -t tmp -i -p execute -c file  
I tried this command on FC5, default policy, and I get 5 rules, two
based on attributes, one rule for initrc_t, and two rules for
logrotate_t.  So most of the cases appear to be attribute-based, likely
one for unconfined domains and not certain about the other.  Being able
to execute files from /tmp is not desirable in general.

>  I see over 30 in a strict version of the reference policy. I
> don't know
>  if the execute access is necessary, but I suspect a lot of things will
>  break if the access is removed. 
-- 
Stephen Smalley
National Security Agency

[Marten Lehmann]

Hello,

>  You can certainly not allow execute permission to *_tmp_t (the types
>  applied to files created in /tmp) in your policy.  In fact, most domains
>  should already be that way. 
but I don't want to create a policy for every single application. Just 
think of file permissions: They are valid for every user, no matter 
which application or service tries to access a certain file. The 
permissions apply for all processes. The same is true if I would mount 
/tmp on a separate partition wich noexec.
So, how can I setup a noexec-policy for /tmp selinux that applies for 
all processes as file permissions or mount options do?

Regards
Marten

On Thu, 11 May 2006 16:00:54 +0200, Marten Lehmann said:

>  So, how can I setup a noexec-policy for /tmp selinux that applies for
>
>  all processes as file permissions or mount options do? 
At some point, you'll have to decide whether to do A or B:

A) Build a custom SELinux policy, and maintain it as reference policy is
updated, and debug all the issues yourself.

B) Bite the bullet, and repartition with a separate /tmp (which is a good
idea even without SELinux, as it kills off a whole class of attacks using
hardlinks from /tmp to places on the root partition).  Personally, I recommend
redoing the disk with LVM, and leaving a bit of unallocated space, so if your
initial guesses for partition sizes is wrong you can grow them on the fly.
My standard Fedora builds have separate /, /boot, /usr, /usr/share, /usr/local,
/var, and /tmp, all with suitably restrictive uses of 'ro', 'noexec',
'nodev',
and 'nosuid'....

[Marten Lehmann]

>  A) Build a custom SELinux policy, and maintain it as reference policy
> is
>  updated, and debug all the issues yourself. 
I just need a hint on how to create a system-wide policy, not just an
application level policy. Where can I find details on this?

>  B) Bite the bullet, and repartition with a separate /tmp (which is a
> good
>  idea even without SELinux, as it kills off a whole class of attacks using
>  hardlinks from /tmp to places on the root partition). 
It is not a technical problem to create a separate partition. But as I wrote
in my first email I just cannot do it, because there is no way in linux to
have system-wide quotas. Quotas are always only valid for one single
partition. If I have quotas on the root partition (which includes /home) but
/tmp is on a separate partition, then the quotas of / (and thus /home) don't
apply for /tmp. That is the only reason why I have a look at selinux.

If you have any other idea to have the same quotas for /home and /tmp while
/tmp doesn't allow to execute files but /home does, then please tell me.

Regards
Marten

[Lamont R. Peterson]

On Thursday 11 May 2006 06:26pm, Marten Lehmann wrote:
>  > A) Build a custom SELinux policy, and maintain it as reference
> policy is
>  > updated, and debug all the issues yourself.
>
>  I just need a hint on how to create a system-wide policy, not just an
>  application level policy. Where can I find details on this?
>
>  > B) Bite the bullet, and repartition with a separate /tmp (which is a good
>  > idea even without SELinux, as it kills off a whole class of attacks using
>  > hardlinks from /tmp to places on the root partition).
>
>  It is not a technical problem to create a separate partition. But as I
>  wrote in my first email I just cannot do it, because there is no way in
>  linux to have system-wide quotas. Quotas are always only valid for one
>  single partition. If I have quotas on the root partition (which includes
>  /home) but /tmp is on a separate partition, then the quotas of / (and thus
>  /home) don't apply for /tmp. That is the only reason why I have a look at
>  selinux.
>
>  If you have any other idea to have the same quotas for /home and /tmp while
>  /tmp doesn't allow to execute files but /home does, then please tell me. 
Do something like this in fstab (obviously, you might want to do something a 
little different with the mount options, but you get the idea):

/	/dev/vg0/root	ext3	defaults 1 1
/home	/dev/vg0/home	ext3	usrquota,grpquota,nosuid 1 2
/tmp	/dev/vg0/tmp	ext3	usrquota,grpquota,noexec,nosuid 1 2

When you want to change the quotas or set them, run:
# setquota username block-soft block-hard inode-soft inode-hard -a

It's the -a at the end that make it set them the same for all filesystems.  
You can have multiple filesystems with quotas and they can have different 
values set.

However, I don't think that's what you really want.  After all, it might make 
sense to limit users to 100MB in their home directory, but maybe only 1MB 
in /tmp/ instead.  Of course, if you have both /tmp/ and /home/ on the same 
filesystem, what's to stop a user with a 100MB from just using it up 
in /tmp/ ?  Nothing.

If the quota limits need to be as strict as your first message indicates, then 
I'm surprised you haven't already had /tmp/ on a separate filesystem, with 
separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
fills, it doesn't "damage" my root filesystem.

HTH.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Marten Lehmann]

>  When you want to change the quotas or set them, run:
>  # setquota username block-soft block-hard inode-soft inode-hard -a 
But I'm looking for a clean way to do it without workarounds with selinux!

The system includes a webserver and when someone uses the fileupload of 
PHP, then the uploaded file will be stored in /tmp. So a quota of just 1 
MB on /tmp for every user is not enough.

>  If the quota limits need to be as strict as your first message
> indicates, then 
>  I'm surprised you haven't already had /tmp/ on a separate filesystem, with 
>  separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
>  fills, it doesn't "damage" my root filesystem. 
Actually, /home is not part of the root-partition and /tmp could be a 
symlink to /home/tmp so both can use the some quota definitions. But how 
can I setup a system-wide policy that disallows to execute files from 
/tmp or /home/tmp?

Regards
Marten

[Stephen Smalley]

On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote:
>  > When you want to change the quotas or set them, run:
>  > # setquota username block-soft block-hard inode-soft inode-hard -a
>  
>  But I'm looking for a clean way to do it without workarounds with selinux!
>  
>  The system includes a webserver and when someone uses the fileupload of 
>  PHP, then the uploaded file will be stored in /tmp. So a quota of just 1 
>  MB on /tmp for every user is not enough.
>  
>  > If the quota limits need to be as strict as your first message indicates, then 
>  > I'm surprised you haven't already had /tmp/ on a separate filesystem, with 
>  > separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
>  > fills, it doesn't "damage" my root filesystem.
>  
>  Actually, /home is not part of the root-partition and /tmp could be a 
>  symlink to /home/tmp so both can use the some quota definitions. But how 
>  can I setup a system-wide policy that disallows to execute files from 
>  /tmp or /home/tmp? 
SELinux permission checks are pair-based checks between the process'
domain and the object type (or to be precise, triple-based, with the
security class as the third component).  They aren't analogous to inode
flags.  So you can achieve the effect of such a policy by not allowing
any process domain execute permission to any file type that can exist
in /tmp, but not in the way you describe.  

-- 
Stephen Smalley
National Security Agency

[Martin Ebourne]

On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote:
>  > If the quota limits need to be as strict as your first message
> indicates, then 
>  > I'm surprised you haven't already had /tmp/ on a separate filesystem, with 
>  > separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
>  > fills, it doesn't "damage" my root filesystem.
>  
>  Actually, /home is not part of the root-partition and /tmp could be a 
>  symlink to /home/tmp so both can use the some quota definitions. But how 
>  can I setup a system-wide policy that disallows to execute files from 
>  /tmp or /home/tmp? 
That sounds like a very hard way of doing things. And difficult to prove
correct too.

How about:

mkdir /home/tmp
mount -o bind,noexec,nosuid /home/tmp /tmp

Much easier, guaranteed secure.

Cheers,

Martin.

[Thomas Bleher]

* Martin Ebourne <lists(a)ebourne.me.uk&gt; [2006-05-12 17:19]:
>  On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote:
>  > > If the quota limits need to be as strict as your first message indicates, then
>
>  > > I'm surprised you haven't already had /tmp/ on a separate filesystem,
> with 
>  > > separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
>  > > fills, it doesn't "damage" my root filesystem.
>  > 
>  > Actually, /home is not part of the root-partition and /tmp could be a 
>  > symlink to /home/tmp so both can use the some quota definitions. But how 
>  > can I setup a system-wide policy that disallows to execute files from 
>  > /tmp or /home/tmp?
>  
>  That sounds like a very hard way of doing things. And difficult to prove
>  correct too.
>  
>  How about:
>  
>  mkdir /home/tmp
>  mount -o bind,noexec,nosuid /home/tmp /tmp 
I don't think this will work. I just tried to do it and I could still
execute files in the mounted dir. I thought that per-mountpoint noexec
flags were in the kernel, but I can't find any definitive information on
it and fs/namespace.c is not the best information source either. (Anyone 
knows why this doesn't work? It would be really neat.)

The other issue here is that the user still can execute files through
/home/tmp. So you should --move the dir instead of bind-mounting it.

Thomas

[Thomas Bleher]

* Thomas Bleher <bleher(a)informatik.uni-muenchen.de&gt; [2006-05-12 20:22]:
>  * Martin Ebourne <lists(a)ebourne.me.uk&gt; [2006-05-12 17:19]:
>  > On Fri, 2006-05-12 at 15:46 +0200, Marten Lehmann wrote:
>  > > > If the quota limits need to be as strict as your first message indicates,
> then 
>  > > > I'm surprised you haven't already had /tmp/ on a separate
> filesystem, with 
>  > > > separate quotas set.  Additionally, I always split off /tmp/ so *if* it 
>  > > > fills, it doesn't "damage" my root filesystem.
>  > > 
>  > > Actually, /home is not part of the root-partition and /tmp could be a 
>  > > symlink to /home/tmp so both can use the some quota definitions. But how 
>  > > can I setup a system-wide policy that disallows to execute files from 
>  > > /tmp or /home/tmp?
>  > 
>  > That sounds like a very hard way of doing things. And difficult to prove
>  > correct too.
>  > 
>  > How about:
>  > 
>  > mkdir /home/tmp
>  > mount -o bind,noexec,nosuid /home/tmp /tmp
>  
>  I don't think this will work. I just tried to do it and I could still
>  execute files in the mounted dir. I thought that per-mountpoint noexec
>  flags were in the kernel, but I can't find any definitive information on
>  it and fs/namespace.c is not the best information source either. (Anyone 
>  knows why this doesn't work? It would be really neat.) 
Umm, this mailing list post explains it:
http://www.cs.helsinki.fi/linux/linux-kernel/2001-41/0082.html (plus
followup from Al Viro).
Mount seems really broken in this regard as it reports the noexec flags
in /etc/mtab.

>  The other issue here is that the user still can execute files
> through
>  /home/tmp. So you should --move the dir instead of bind-mounting it. 
There's another issue here: You can't mount --move a directory that is
not a mountpoint. So if you want to guard against people accessing
/home/tmp directly, either move it to /home/secure/tmp and bind-mount it
from there (where /home/secure is mode 0000), or bind mount /home/tmp
over itself.

That means a fully working solution looks something like this:
$ mount --bind /home/tmp/ /home/tmp/
$ mount -o remount,noexec /home/tmp/
$ mount --bind /home/tmp/ /tmp/

Lesson learnt here: Test to see if you actually protect against your
threats.

Thomas

[Lamont R. Peterson]

On Friday 12 May 2006 07:46, Marten Lehmann wrote:
>  > When you want to change the quotas or set them, run:
>  > # setquota username block-soft block-hard inode-soft inode-hard -a
>
>  But I'm looking for a clean way to do it without workarounds with selinux! 
That's not an SELinux command, that's quota management.

So, if you do *not* want to use SELinux, then why is this thread on this list?  
Or am I misunderstanding what you are saying there?

>  The system includes a webserver and when someone uses the fileupload
> of
>  PHP, then the uploaded file will be stored in /tmp. 
That is not a good idea.  Instead, either create a separate location on your 
filesystem(s).  It is dangerous to allow any network access of any kind 
to /tmp/.

For that purpose, change the app to upload the files to a directory somewhere 
on the system that has a subdirectory for each user and you can then symlink 
the per-user subdirectories into each user's home directory.  Or, you could 
just have the app upload files into the particular user's home directory.  
Both of these options would be much better (from a security standpoint) than 
what you are currently trying to do.

>  So a quota of just 1 
>  MB on /tmp for every user is not enough. 
Well, 1MB was just a relative number I used as  an example.

>  > If the quota limits need to be as strict as your first message
> indicates,
>  > then I'm surprised you haven't already had /tmp/ on a separate
>  > filesystem, with separate quotas set.  Additionally, I always split off
>  > /tmp/ so *if* it fills, it doesn't "damage" my root filesystem.
>
>  Actually, /home is not part of the root-partition 
Yes, I understood that.  You asked how to make them share the same quota-space 
and that would require them to be on the same partition.  So, I phrased that 
as an example of having both /home/ and /tmp/ on a common filesystem.  Sorry 
for the confusion, there.

>  and /tmp could be a 
>  symlink to /home/tmp so both can use the some quota definitions. But how
>  can I setup a system-wide policy that disallows to execute files from
>  /tmp or /home/tmp? 
The best way, as I see it, is to stop trying to use /tmp/ for this.  If the 
reason you are using /tmp/ is because you want old files to be removed 
automatically once they get "stale enough," then create your own cron job 
that runs tmpwatch and clears your upload director(y|ies).  Simple.  More 
secure.  No danger in /tmp/.  Quotas could be applied as you like.
-- 
Lamont R. Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
GPG Key fingerprint: F98C E31A 5C4C 834A BCAB  8CB3 F980 6C97 DC0D D409

[Marten Lehmann]

Hello,

>  That means a fully working solution looks something like this:
>  $ mount --bind /home/tmp/ /home/tmp/
>  $ mount -o remount,noexec /home/tmp/
>  $ mount --bind /home/tmp/ /tmp/ 
thanks, it really works. It even works after adding appropriate lines to 
/etc/fstab so this is automatically done at boot time (I was afraid that 
mount woudln't like entries with duplicate mountpoints).

Regards
Marten

[Paul Howarth]

On Wed, 2006-06-07 at 18:03 +0200, Marten Lehmann wrote:
>  Hello,
>  
>  > That means a fully working solution looks something like this:
>  > $ mount --bind /home/tmp/ /home/tmp/
>  > $ mount -o remount,noexec /home/tmp/
>  > $ mount --bind /home/tmp/ /tmp/
>  
>  thanks, it really works. It even works after adding appropriate lines to 
>  /etc/fstab so this is automatically done at boot time (I was afraid that 
>  mount woudln't like entries with duplicate mountpoints). 
Watch out if/when you come to upgrade this system; FC5's anaconda was
confused by bind mounts in fstab and they needed to be commented out
before doing the upgrade,

Paul.

On Wed, 07 Jun 2006 18:03:18 +0200, Marten Lehmann said:
>  Hello,
>  
>  > That means a fully working solution looks something like this:
>  > $ mount --bind /home/tmp/ /home/tmp/
>  > $ mount -o remount,noexec /home/tmp/
>  > $ mount --bind /home/tmp/ /tmp/
>  
>  thanks, it really works. It even works after adding appropriate lines to 
>  /etc/fstab so this is automatically done at boot time (I was afraid that 
>  mount woudln't like entries with duplicate mountpoints). 
You might also want to look at the pam_namespace code that's in Rawhide
right now... Per-userid /tmp and neat stuff like that....