On Mon, May 9, 2011 at 11:00 PM, David Lutterkort <lutter(a)redhat.com> wrote:
On Mon, 2011-05-09 at 22:42 +0200, Alan Pevec wrote:
> On 05/09/2011 11:44 AM, Radek Novacek wrote:
> > I finally published augeas-based agent. You can find it in my repo on github
> > [1]. It is now done as standalone agent out of matahari tree, but it should be
> > easy to integrate it into Matahari.
Very nice :)
> > Since those method aren't stateless there are some security issues. For
> > example: User creates his session, change some files and saves (after
> > authorization check by polkit). But all DBus communication is public, so
> > anyone can use same handle to changed other files before user saves. All
> > changes will be saved no matter who did them.
That's a serious concern, since that gives anybody write access to large
swaths of the file system.
> > To aviod this issue two precautions were made. Init takes name of augeas'
lens
> > as argument and won't load any other lenses. It should minimize the impact
of
> > this issue, but it's a little bit hackish and user unfriendly (need to know
> > the name of the lens).
If you expose the entire augeas API, it also won't keep people from
modifying random files; all they need to do is set up transforms
under /augeas/load themselves, and then do an aug_load.
A cleaner solution would be to add functionality to restrict what a user
can modify. For example, we could add the convention that we respect a
list path expressions underneath /augeas/restrict; if there is anything
in that subtree, the user will only be allowed to read/write parts of
the tree that match. For example, we could do
clear /augeas/restrict # Set to NULL so that checking is turned off
rm /augeas/restrict/*
set /augeas/restrict/incl /files/etc/hosts
set /augeas/restrict/incl /files/etc/inittab
set /augeas/restrict/incl /augeas/files
set /augeas/restrict enforce
After this, the user would only be allowed to read/write/modify the
subtrees /files/etc/hosts, /files/etc/inittab, and /augeas/files
Could an attacker not simply add files to that list?
> I would avoid state by not publishing direct augeas API.
> Instead, why not accept a list of changes and perform it atomically in one call?
That's what the augeas type for puppet does[1] It takes a string with
augtool-like commands, executes them and then saves the resulting tree.
Since this has now been implemented twice (in Ruby for puppet, in C for
augtool) it might be time to move that functionality into the Augeas API
proper.
Sounds like a good path forward.
Would it make sense to borrow the augtool C code until it makes it
into the proper API?