Date: Mon, 18 Sep 2000 15:25:51 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-security@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c (fwd) Message-ID: <Pine.NEB.3.96L.1000918152214.27277D-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Thought this might be of interest to some readers here. As part of the capabilities support in the TrustedBSD tree, I have started doing a cataloging of the use of privilege within the FreeBSD source tree. In response to a question from Garrett Wollman, I pasted some sections into a recent e-mail relating to a UFS suser-related commit. If there are any question or comments, I'd be glad to hear them, either on this mailing list, or on the trustedbsd-discuss@trustedbsd.org mailing list. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Mon, 18 Sep 2000 14:53:54 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: developers@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c Robert Watson wrote: > The following is a list of assertions of privilege that occur within the > UFS source tree. In each case, I attempt to document the situation, the > use of privilege, and whether or not that is a safe use in the context of > jail() process containment. I'd welcome any corrections. Just for reference, I'm going to throw in the mapping of these privileges to POSIX.1e and Linux capabilities. I also left out two uses of privilege: (1) Relating to the adding of the sticky-bit to files, which I recently disabled. Prior to that, privilege could be asserted to allow the sticky bit to be set on objects other than directories, rather than returning EFTYPE. I put this down as a historical curiosity, but feedback on that change would also be welcome; as such, there is no capability reflecting this privilege in my implementation. (2) vaccess() called by ufs_access() allows privilege to override discretionary restrictions on the reading, writing, and executing of files. For files, these map into CAP_DAC_READ_SEARCH, CAP_DAC_WRITE, and CAP_DAC_EXECUTE. For directories, CAP_DAC_READ_SEARCH, CAP_DAC_WRITE, and CAP_DAC_READ_SEARCH (lookup permission). The implementation commited to vfs_subr() isn't quite in synch with this, but it is not enabled so not an issue. > ufs_extattrctl(): If a process wishes to configure extended attribute > support on a UFS file system, it must assert privilege. The assertion of > this privilege is not safe within jail(). CAP_SYS_ADMIN > ufs_extattr_credcheck(): If a process wishes to read or modify a system > namespace extended attribute, it must assert privilege. The assertion of > this privilege is not safe within jail(). CAP_SYS_ADMIN > ufs_lookup(): If a process wishes to remove a file from a directory, and > the directory has the sticky bit set, then either the process must own the > directory, or must own the file to be deleted, unless privilege is > asserted. The assertion of this privilege is safe within jail(). CAP_DAC_WRITE > WRITE(): If a process writes to a file, either by virtue of discretionary > access rights, or assertion of privilege, the setuid and setgid bits will > be removed from that file, unless privilege is asserted. The assertion of > this privilege is safe within jail(). CAP_FSETID > ufs_setattr(): A process is permitted to change the user file flags of a > file if the process has a uid matching that of a file, or via the > assertion of privilege. The assertion of this privilege should be safe > within jail(). CAP_FOWNER > ufs_setattr(): A process is permitted to set system flags of a file via > the assertion of privilege. The assertion of this privilege is not safe > within jail(). CAP_SYS_SETFFLAG ("CAP_LINUX_IMMUTABLE" in Linux-speak) > ufs_setattr(): A process is permitted to change the file utimes if it may > modify the file via discretionary access rights, or via assertion of > privilege. The assertion of this privilege should be safe within jail(). CAP_FOWNER > ufs_chmod(): A process changing the mode of the file is permitted to do so > based on file ownership or assertion of privilege. However, if the sgid > bit will be enabled in the final mode, either the process must be a member > of the group of the file, or privilege must be asserted. The assertion of > these privileges should be safe within jail(). Generally, CAP_FOWNER is used to override ownership requirements, except in the case of setting the setuid and setgid bits, in which case it is CAP_FSETID. Both might be asserted in a particular call. > ufs_chown(): A process is permitted to change the ownership related to a > file only in the following situations: > > (1) To change the owner of a file, the process must assert privilege. CAP_CHOWN > (2) To change the group of the file, the process effective uid must > be the same as the owner of the file, and the target group of the > file must be in the process's effective group membership, or the > process must assert privilege. CAP_CHOWN > The assertion of this privilege should be safe within jail(). > > ufs_chown(): If a process changes the ownership of a file, and either the > owner or the group of the file changes, then unless privilege is asserted, > the setuid and setgid bits on the file will be removed. Ths assertion of > this privilege should be safe within jail(). CAP_FSETID > ufs_rename(): If the process attempts to rename a file and the target > directory of the rename has the sticky bit set, the process must own the > target directory of the rename or the file to be overwritten by the > rename, unless it asserts privilege. The assertion of this privilege > should be safe within jail(). CAP_DAC_WRITE > ufs_makeinode(): If a process creates a new file and requests that the > setgid bid be set, the process must be a member of the group with the gid > of the file, or the setgid bit cannot be set without the assertion of > privilege. The assertion of this privilege should be safe within jail(). CAP_FSETID > There are additional assertions of privilege associated with the quota > code. I have not attempted to understand them fully as yet, so they're > not on my list of jail-safe or jail-not-safe yet. My guess is that they > are split into two categories, one relating to the configuration and > management of quotas, and the other related to quota interaction based on > chown and friends. They will need similar analysis. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000918152214.27277D-100000>