All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Paul FM <paulfm@me.umn.edu>, linux-ext4@vger.kernel.org
Subject: Re: noacl and nouser_xattr
Date: Mon, 18 Nov 2013 12:31:24 -0600	[thread overview]
Message-ID: <528A5CFC.1060706@redhat.com> (raw)
In-Reply-To: <528A2397.8030402@me.umn.edu>

On 11/18/13, 8:26 AM, Paul FM wrote:
> 
> Yes - I need noacl and nouser_xattr
> 
> How about documenting your intent to remove them in the man pages.
> 
> acl support and user_xattr support need to be off on the / and /usr
> filesystems to simplify security. Actually I want a way to turn off
> ALL extended attribute support on any filesystem.  How about noxattr
> (which would turn off ALL extended attribute support including acls).
> I also use nosuid on filesystems that shouldn't have any suid files.
> 
> This is to follow the security principal - "If you aren't using it
> and don't need it - turn it off".

FWIW, it still can be disabled at build time via CONFIG_EXT3_FS_POSIX_ACL

But if you are using a distro kernel that turns that on, I see
your point about noacl.

However, I'm not sure how nouser_xattr comes into the argument?
xattrs by themselves are just metadata; they don't impact security
control unless they are a special kind of xattrs (i.e. acls).

Thanks,
-Eric

> The simple Posix/Unix permissions are more than enough security
> control in almost every situation I have run into (only wish I could
> use them in Windows).
> 
> Having worked extensively with ACLS on Windows (and some older Main
> Frame OSes) - I note that ACL's add a level of complexity to security
> that actually makes for less security.  I see the need to support
> them in Unix/Linux - but they should be OFF unless someone
> specifically wants to use them (at least don't make them hard to turn
> off).
> 
> Just try auditing the security of a windows filesystem if you don't
> think ACL's add extreme complexity (I gave up - I just forcibily set
> all the ACL's myself by script using the unix Owner,Group,Other
> concepts as a model to simplify what I am setting).
> 
> 
> 
> 


  reply	other threads:[~2013-11-18 18:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 14:26 noacl and nouser_xattr Paul FM
2013-11-18 18:31 ` Eric Sandeen [this message]
2024-04-01 16:54   ` Paul Markfort

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528A5CFC.1060706@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=paulfm@me.umn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.