On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote:
> There's an AFS userspace command that could be used to query a mountpoint that
> was going to use it. However, I suspect readlink() will now always trigger
> the automount.
It won't, actually. All we are passing to user_path_at_em
On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote:
> Al Viro wrote:
>
> > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to
> > POSIX it should do so (with -EINVAL). There is a pathological case when
> > it succeeds for a directory, tho
On Thu, Nov 19, 2015 at 07:16:32PM -0800, Linus Torvalds wrote:
> .. it's not necessarily just readlink() either. I still think it might
> be a perfectly fine idea to allow non-directories to act as
> directories in some case (by exposing "readdir" and "lookup").
As soon as we expose ->lookup(),
On Thu, Nov 19, 2015 at 06:13:53PM -0800, Linus Torvalds wrote:
> > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to
> > POSIX it should do so (with -EINVAL).
>
> I don't think POSIX is necessarily relevant here.
>
> We have had magic file behavior outside the scope of PO
I'd been looking through ->readlink() callers, and there are
several areas where behaviour looks wrong.
1) atime updates, according to POSIX, should happen in case of success.
For example, giving readlink(2) an unmapped buffer should _not_ touch
atime. Neither should calling readlink(2) i
On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote:
> Yes, the host admin. I'm not talking about trusting the admin inside the
> container at all.
Then why not have the same host admin just plain mount it when setting the
container up and be done with that? From the host namespace, bef
On Wed, Nov 18, 2015 at 08:22:38AM -0600, Seth Forshee wrote:
> But it still requires the admin set it up that way, no? And aren't
> privileges required to set up those devices in the first place?
>
> I'm not saying that it wouldn't be a good idea to lock down the backing
> stores for those types
On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:
> >This is absolutely insane, no matter how much LSM snake oil you slatter on
> >the whole thing. All of a sudden you are exposing a huge attack surface
> >in the place where it would hurt most and as the consolation we are offe
On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:
> >_Static_ attacks, or change-image-under-mounted-fs attacks?
> To properly protect against attacks on mounted filesystems, we'd
> need some new concept of a userspace immutable file (that is, one
> where nobody can write to it
On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> Shortly after that I plan to follow with support for ext4. I've been
> fuzzing ext4 for a while now and it has held up well, and I'm currently
> working on hand-crafted attacks. Ted has commented privately (to others,
> not to me pers
On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> Hi Eric,
>
> Here's another update to my patches for user namespace mounts, based on
> your for-testing branch. These patches add safeguards necessary to allow
> unprivileged mounts and update SELinux and Smack to safely handle
> devi
On Wed, Oct 14, 2015 at 02:41:57PM +0200, Lukasz Pawelczyk wrote:
> int (*getprocattr)(struct task_struct *p, char *name, char **value);
> - int (*setprocattr)(struct task_struct *p, char *name, void *value,
> - size_t size);
> + int (*setprocattr)(struct t
On Mon, Feb 18, 2008 at 09:03:51AM +0900, Tetsuo Handa wrote:
> Hello.
>
> > No printable comments, except for that:
> >
> > (e) why don't you guys move the Linus' Serious Mistake to _callers_ of
> > vfs_mknod() and its ilk?
> >
> > Which obviously solves all problems with having vfsmount.
>
>
On Sun, Feb 17, 2008 at 06:00:30PM +0900, Tetsuo Handa wrote:
> Hello.
>
> This is "(c) Add new hooks." approach I proposed at
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg11536.html .
>
> Although this is an incomplete patch,
> I want to know whether you can tolerate this approach or not.
On Fri, Jan 25, 2008 at 07:20:56PM +0900, Kentaro Takeda wrote:
> In the LSM ml, we are discussing about
> "how to know requested pathnames within LSM modules".
>
> Currently, VFS helper functions don't pass "struct vfsmount" parameter.
> Therefore, we cannot calculate requested pathnames within L
On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote:
> Defense in depth has long been recognised as an important secure design
> principle. Security is best achieved using a layered approach.
"Layered approach" is not a magic incantation to excuse any bit of snake
oil. Homeopathic remedies m
On Sat, Oct 27, 2007 at 11:01:12AM +0200, Ahmed S. Darwish wrote:
> The problem here (As discussed in private mails) is that the for loop
> assumes that the beginning of given user-space buffer is the beginning
> of a rule. This leads to situations where the rule becomes "ecret 20",
> or "cret 20"
On Fri, Oct 26, 2007 at 11:23:53AM -0700, John Johansen wrote:
> In the current code, both vfsmounts are always identical, and so one of
> the two should go, agreed.
>
> The thought behind passing both vfsmounts was that they could differ but
> point to the same super_block, in which case renames
On Thu, Oct 25, 2007 at 11:40:43PM -0700, [EMAIL PROTECTED] wrote:
> The vfsmount will be passed down to the LSM hook so that LSMs can compute
> pathnames.
You know, you really are supposed to understand the code you are modifying...
Quiz: what are those vfsmounts and how are they related?
Al, ca
On Thu, Oct 18, 2007 at 01:13:02PM -0700, Casey Schaufler wrote:
> CPU1 sets smk_next to smack_known.
> CPU1 fills in the rest of the entry.
> CPU1 sets smack_known to skp (the entry).
>
> CPU2 will either see the old value for smack_known,
> in which case this entry isn't actually on the list y
On Thu, Oct 18, 2007 at 05:57:05AM +0100, Al Viro wrote:
> On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
> Think what happens if CPU1 adds to list and CPU2 sees write to smk_known
> *before* it sees write to ->smk_next. We see a single-element list and
> we'
On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
At random:
> +static int smack_netlabel(struct sock *sk)
> +{
> + static int initialized;
> + struct socket_smack *ssp = sk->sk_security;
> + struct netlbl_lsm_secattr secattr;
> + int rc = 0;
> +
> + if (!initia
On Sun, Oct 14, 2007 at 10:15:42AM -0700, Casey Schaufler wrote:
> This version fixes a major blunder in label handling. The system
> works, but has a serious memory leak that also induces a gradual
> performance degradation. Al Viro gets the credit for pointing out
> that one.
On Fri, Oct 12, 2007 at 10:01:17PM -0700, Casey Schaufler wrote:
What do you need smk_sb for? Looks like dead weight...
smk_read_load(): obvious seq_file candidate.
smk_read_cipso(): ditto.
What protects smk_cipso_written? BTW, its use on the read side is an
atrocity...
smk_write_doi() - WTF
On Wed, Oct 03, 2007 at 03:23:15PM -0700, Casey Schaufler wrote:
> 1. Create /moldy at "_"
> 2. For each label you care about
>2a. Create /moldy/
>2b. Set the label of /moldy/ to
> 3. ln -s /smack/tmp /tmp
> 1. Create /moldy at "_"
> 2. For each label you care about
>2a. Create /moldy
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote:
> > > Because you throw "simple" out the window when you require userland
> > > assistance to perform this function.
> >
> > Any more than having /tmp replaced with a symlink?
>
> Yes. By the way, there's nothing that really require
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote:
> > Absolute paths in that kind of thing are _wrong_. You know where the things
> > are on your fs. You don't know if anything else will be visible, let alone
> > whether it will be at the same place in all chroots or namespaces. And no,
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote:
> > what
> > happens if we want it in two chroot jails with different layouts?
>
> As you can only have /smack mounted once, this isn't an issue,
> but it does present an interesting use case that brings the one
> mount limitation in
On Tue, Oct 02, 2007 at 09:45:42PM -0700, Casey Schaufler wrote:
>
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, S
On Wed, Sep 19, 2007 at 09:11:26PM -0700, Andrew Morgan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Howells wrote:
> > Move the effective capabilities mask from the task struct into the
> > credentials
> > record.
> >
> > Note that the effective capabilities mask in the cr
On Wed, Sep 26, 2007 at 03:21:05PM +0100, David Howells wrote:
> To alter the credentials record, a copy must be made. This copy may then be
> altered and then the pointer in the task_struct redirected to it. From that
> point on the new record should be considered immutable.
Umm... Perhaps a b
On Fri, Aug 31, 2007 at 10:46:02AM -0500, Mikel L. Matthews wrote:
> >Let me say it again: that's how mandatory access control is supposed to
> >work. A program (or user) isn't supposed to be able to delegate access
> >under a mandatory policy.
>
> How about looking at it this way, I am work for
On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote:
> I personally consider this an affront to everythign that is decent.
>
> Why the *hell* would mkdir() be so magical as to need something like that?
>
> Make it something sane, like a "struct nameidata" instead, and make it at
> lea
On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
> Read it like this: we don't have a good idea how to support multiple
> namespaces so far. Currently, we interpret all pathnames relative to the
> namespace a process is in. Confined processes don't have the privilege to
> cr
On Thu, Apr 12, 2007 at 11:32:00AM +0100, Al Viro wrote:
> On Thu, Apr 12, 2007 at 02:08:49AM -0700, [EMAIL PROTECTED] wrote:
> > + } else if (profile1 > profile2) {
> > + /* profile1 cannot be NULL here. */
> > + spin_lock_irqsave(&profile
> +char *d_namespace_path(struct dentry *dentry, struct vfsmount *vfsmnt,
> +char *buf, int buflen)
> +{
> + char *res;
> + struct vfsmount *rootmnt, *nsrootmnt;
> + struct dentry *root;
> +
> + read_lock(¤t->fs->lock);
> + rootmnt = mntget(current->fs->rootm
On Thu, Apr 12, 2007 at 02:08:49AM -0700, [EMAIL PROTECTED] wrote:
> + } else if (profile1 > profile2) {
> + /* profile1 cannot be NULL here. */
> + spin_lock_irqsave(&profile1->lock, profile1->int_flags);
> + if (profile2)
> + spin_lock(&
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
> This is needed for computing pathnames in the AppArmor LSM.
Which is an argument against said LSM in current form.
> - error = security_inode_create(dir, dentry, mode);
> + error = security_inode_create(dir, dentry, nd
[apologies for resend, bogus address on the original mail]
security_getprocattr() takes a buffer + length, copies data
to it and return the actual length. If buffer is NULL, it just returns
the right length, a-la snprintf(). Observations:
* at least selinux ends up actually alloc
security_getprocattr() takes a buffer + length, copies data
to it and return the actual length. If buffer is NULL, it just returns
the right length, a-la snprintf(). Observations:
* at least selinux ends up actually allocating the buffer of the
right size, filling it, then copying
40 matches
Mail list logo
