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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ