linux-kernel - Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707032201.47586.agruen@suse.de>
Date:	Tue, 3 Jul 2007 22:01:47 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	James Morris <jmorris@...ei.org>,
	John Johansen <jjohansen@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Miklos Szeredi <mszeredi@...e.cz>
Subject: Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

On Tuesday 03 July 2007 15:49, Stephen Smalley wrote:
> So you don't actually need/use the struct file pointer; you just need a
> flag indicating whether or not access was by open file descriptor or by
> pathname?

Yes, indeed. Given that struct iattr already defines ATTR_FILE and ia_file, I 
didn't see a good reason to invent something new when we can just use the 
existing mechanism.

> And what does this mean for a process that has "changed hats"?  Which
> might not be authorized to access the file anymore, even via an already
> opened descriptor.

If that file is still part of the namespace (i.e., not deleted), then access 
to the file descriptor is revalidated against the new profile ("changing hat" 
is switching to a different profile). If the file has already been deleted, 
then access is granted. There isn't that much of a difference between a 
deleted file and say, and anonymous pipe: both can be used by processes to 
communicate, and both will cease their lives once no longer referenced.

Later with IPC mediation, we'll obviously have to control which profiles may 
communicate with which other profiles. One possibility for that would be to 
map profiles and allowed communication channels to labels and access rules.

Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/