Hi, Am I right to assume ZFS currently doesn''t support the least privilege model ? I''m trying to make bacula run as non root on zfs and be able to restore files a non-root with the correct least privilege modes but when I enable debugging with ppriv -D <pid> I get Nov 5 20:39:27 corona genunix: [ID 702911 kern.notice] bacula-fd[9685]: missing privilege "ALL" (euid = 110, syscall = 5) needed at zfs_zaccess+0x1fc Currently I have the following privs for bacula: basic file_chown file_chown_self file_dac_read file_dac_search file_dac_write file_owner file_setid file_flag_set and thought I would get the priv that is missing when running the debugging. Marco -- This message posted from opensolaris.org
Marco van Wieringen wrote:> Hi, > > Am I right to assume ZFS currently doesn''t support the least privilege model ?No you are not correct it does support privileges.> I''m trying to make bacula run as non root on zfs and be able to restore > files a non-root with the correct least privilege modes but when I > enable debugging with ppriv -D <pid> I get > > Nov 5 20:39:27 corona genunix: [ID 702911 kern.notice] bacula-fd[9685]: missing privilege "ALL" (euid = 110, syscall = 5) needed at zfs_zaccess+0x1fcsyscall 5 is open(2). That likely means you are trying to write to a root owned file which requires ALL privilege otherwise file_dac_write is equivalent to all privileges. See the privileges(5) man page for a detailed explanation. UFS and tmpfs have the same behaviour. I recommend reading the Sun Blueprint "Privilege Debugging in the Solaris 10 Operating System" which you can find off the OpenSolaris Security web page: http://hub.opensolaris.org/bin/view/Community+Group+security/library or directly at: http://www.sun.com/blueprints/0206/819-5507.pdf -- Darren J Moffat
>Hi, > >Am I right to assume ZFS currently doesn''t support the least privilege model ? >I''m trying to make bacula run as non root on zfs and be able to restore >files a non-root with the correct least privilege modes but when I >enable debugging with ppriv -D <pid> I get > >Nov 5 20:39:27 corona genunix: [ID 702911 kern.notice] bacula-fd[9685]: missing privilege "ALL" (euid = 110, syscall = 5) needed at zfs_zaccess+0x1fc> >Currently I have the following privs for bacula: > >basic >file_chown >file_chown_self >file_dac_read >file_dac_search >file_dac_write >file_owner >file_setid >file_flag_set > >and thought I would get the priv that is missing when running the debugging.In the absence of MAC (Mandatory Access Control), we have made root owned objects behave differently. This is done to prevent "escalation of privileges". E.g., if you have "file_dac_write" you could write to /etc/passwd and give yourself root access. In order to write to a root owned object, you will need "all privileges" because by writing to a root owned file you can get all privileges. Try this with a non-root owned file. Casper
> > In the absence of MAC (Mandatory Access Control), we > have made root owned > objects behave differently. This is done to prevent > "escalation of > privileges". E.g., if you have "file_dac_write" you > could write to > /etc/passwd and give yourself root access. In order > to write to a root > owned object, you will need "all privileges" because > by writing to a root > owned file you can get all privileges. >Ok, that sound reasonable. With the options I need to enable for the restore maybe the all privilege is not to bad.> Try this with a non-root owned file.This happens for this particular case with a new file created in a root owned directory, so I''m not overwriting a root owned object. But it clear now I will use all then. Thanks for getting me in the right direction. Marco -- This message posted from opensolaris.org
>Ok, that sound reasonable. With the options I need >to enable for the restore maybe the all privilege is not to bad. > >> Try this with a non-root owned file. >This happens for this particular case with a new file created >in a root owned directory, so I''m not overwriting a root owned >object. But it clear now I will use all then. >Right, but you''re still modifying a root owned file. Casper
On Thu, Nov 05, 2009 at 12:07:32PM -0800, Marco van Wieringen wrote:> Hi, > > Am I right to assume ZFS currently doesn''t support the least privilege model ? > I''m trying to make bacula run as non root on zfs and be able to restore > files a non-root with the correct least privilege modes but when I > enable debugging with ppriv -D <pid> I get > > Nov 5 20:39:27 corona genunix: [ID 702911 kern.notice] bacula-fd[9685]: missing privilege "ALL" (euid = 110, syscall = 5) needed at zfs_zaccess+0x1fc > > Currently I have the following privs for bacula: > > basic > file_chown > file_chown_self > file_dac_read > file_dac_search > file_dac_write > file_owner > file_setid > file_flag_set > > and thought I would get the priv that is missing when running the debugging.I implemented a feature in FreeBSD/ZFS that I call super-owner. When turned on, file system owner (user that mounted the given file system) can perform operations that normally need special privileges. Bascially he has root privileges for his file systems - he can use chown(2), he can open any file for writing, etc. There are two main use cases I found for it: 1. We have a performance cluster for use by FreeBSD developers where there is one main machine, which acts as NFS server and test machines are netbooted from it. We want developers to be able to modify their test machines from within NFS server without giving them root access. With this feature they can modify any file within file systems used by their test machines. 2. When you have backup server you can create unprivileged user for every machine and create file system per machine. Each file system is owned by one of such unprivileged users. You can then safely backup your servers without giving them root access to the backup server or assigning global privileges to them - they can modify only their own file systems, but they have full rights within them. Before you ask, such file systems are always mounted with nosuid mount option. This feature is also turned off by default. This would be nice feature to have in ZFS. It would be probably best implemented as another ''zfs allow'' permission, eg. ''admin'' or something. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091106/a39a2f2d/attachment.bin>
On Fri, Nov 06, 2009 at 08:36:21PM +0100, Pawel Jakub Dawidek wrote:> I implemented a feature in FreeBSD/ZFS that I call super-owner. When > turned on, file system owner (user that mounted the given file system) > can perform operations that normally need special privileges. Bascially > he has root privileges for his file systems - he can use chown(2), he > can open any file for writing, etc.I can see this being useful, but, beware! Just because you have the right (privilege or authorization) to mount a dataset does not mean that you''re somehow the "owner" of the dataset. Nor, for that matter, would you want to let a dataset''s owner create set-uid 0 executables! I think it''d be fair to say that to specify a "super-owner" you should have ALL privileges when you do it. Nico --