You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Amarjeet Singh <am...@gmail.com> on 2018/01/06 18:58:58 UTC
Same shared Drive redirected to all users : Privacy and Security breach
Hi Team,
I have redirected shared drive on Windows server 2012 R 2. I have 5 users
in that machine.
I have mapped this drive to one of the folder of Centos 7 where guacamole
server runs.
Now, all the users are getting the same shared drive folder.
It means one user can access files of other users. It is very dangerous.
It is breach of security and privacy as well.
Is it any configuration I am missing ?
Data of the user should be deleted once the session is disconnected
otherwise it will occupy whole lot of space in the server [ where
guacamole server runs ].
It will definitely cause the server down.
Every user 's shared drive should not be same.
And we cannot assign 50 user different folder location every time.
Please help me out here .
Thanks and Regards,
Amarjeet Singh
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Nick Couchman <vn...@apache.org>.
On Sun, Jan 7, 2018 at 10:09 AM, Amarjeet Singh <am...@gmail.com>
wrote:
> Nick, Requirement is not to save username and password anywhere. It should
> be logged in by the user itself.
>
>
Yes, I understand and agree.
> That is causing issue to create shared drive with username or
> ${GUAC_USERNAME}
>
I don't think so. The ${GUAC_USERNAME} and ${GUAC_PASSWORD} tokens come
from the username and password that the user logs into *Guacamole* with,
not the username/password for the connection.
As an example, if let's say you have Guacamole configured to use LDAP
authentication, and you are storing your connections in JDBC. Guacamole
LDAP is configured to point to Active Directory, and you have a user,
test_user, and the LDAP/AD password for that user is DoNotCopyMe. The user
is connecting to a Windows server, via RDP, joined to the same AD domain
where LDAP is configured, server1. Here's how the flow would work:
- User logs into Guacamole at https://guacamole.example.com/guacamole, with
username test_user and password DoNotCopyMe
- Guacamole, upon successful login, registers ${GUAC_USERNAME} as test_user
and ${GUAC_PASSWORD} as DoNotCopyMe.
- The user starts the connection to server1, which has the username
parameter set to ${GUAC_USERNAME}, the password parameter set to
${GUAC_PASSWORD}, and the Drive Path parameter set to /tmp/${GUAC_USERNAME}.
- The connection automatically logs into the server because the Guacamole
username and password is passed through to the RDP connection through the
tokens.
- The connection maps the /tmp/test_user directory through to the RDP
connection by resolving the username token.
>
> ${GUAC_USERNAME} works if Single sign on is there i.e. username and
> password is provided. it fails if username and password is not there.
>
>
Well, that depends on what you mean by "Single sign on" and "is [not]
there." The actual username and password do not have to be saved in the
connection in order to be made available; however, the user has to log in
to be logging in to Guacamole. So, if you're using some sort of anonymous
Guacamole authentication (the deprecated noauth extension, for example),
then the GUAC_USERNAME and GUAC_PASSWORD tokens will not be available. If
you're using a SSO login method (OpenID, SAML, CAS without ClearPass), then
the GUAC_USERNAME token will be available while the GUAC_PASSWORD token may
or may not, depending on your configuration. If you're using LDAP or JDBC,
then both the GUAC_USERNAME and GUAC_PASSWORD token should be available.
How are your users authenticating to Guacamole?
-Nick
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Amarjeet Singh <am...@gmail.com>.
Nick, Requirement is not to save username and password anywhere. It should
be logged in by the user itself.
That is causing issue to create shared drive with username or
${GUAC_USERNAME}
${GUAC_USERNAME} works if Single sign on is there i.e. username and
password is provided. it fails if username and password is not there.
On Sun, Jan 7, 2018 at 8:29 PM, Nick Couchman <vn...@apache.org> wrote:
>
> On Sun, Jan 7, 2018 at 9:48 AM Amarjeet Singh <am...@gmail.com>
> wrote:
>
>> If I don't pass username and password then ${GUAC_USERNAME} fails to
>> resolve [ *Scenario : I want users to enter username and password on
>> Windows screen* ]. It create directory with it's own name i.e.
>> ${GUAC_USERNAME}
>>
>>
>> So, Creating filesystem solved this issue and It created directories of
>> users at runtime using "*enable-create-drive*" parameter.
>>
>> Now, I need to look into the following to achieve quotas per sub-volumes
>> or each user's directory. :-
>>
>> ZFS or btrfs, for example, allow for sub-volumes and quotas per-volume,
>>> per-user, and/or per-group
>>>
>>
>> Using SFTP is a good idea though but in case I want the user to enter *username
>> and password* on the Windows screen then It would fail.
>>
>> *Can't save username and password on the user-mapping.xml file for
>> security purposes.*
>>
>
> I would not use the user-mapping.xml file for the size of production
> environment that you're using. First, I'm not certain that the tokens
> (${GUAC_USERNAME} and ${GUAC_PASSWORD}) actually work with the simple/basic
> file authentication mechanism. Mike can verify this. Second, storing
> usernames/passwords in user-mapping.xml for 500 users seems like a bad idea.
>
> If you're considering scaling to this level, I suggest using one or more
> of the extension modules for authentication - at least the JDBC module, and
> perhaps that in combination with something, like LDAP. If you're using
> active directory for the Windows servers you're connecting to this makes a
> lot of sense, because the username/password used to log in to Guacamole
> will match to the servers you're logging into. If you're not, it still
> might make sense to track users in some sort of database - either JDBC or
> LDAP - as this will provide continuity across the environment.
>
> -Nick
>
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Nick Couchman <vn...@apache.org>.
On Sun, Jan 7, 2018 at 9:48 AM Amarjeet Singh <am...@gmail.com> wrote:
> If I don't pass username and password then ${GUAC_USERNAME} fails to
> resolve [ *Scenario : I want users to enter username and password on
> Windows screen* ]. It create directory with it's own name i.e.
> ${GUAC_USERNAME}
>
>
> So, Creating filesystem solved this issue and It created directories of
> users at runtime using "*enable-create-drive*" parameter.
>
> Now, I need to look into the following to achieve quotas per sub-volumes
> or each user's directory. :-
>
> ZFS or btrfs, for example, allow for sub-volumes and quotas per-volume,
>> per-user, and/or per-group
>>
>
> Using SFTP is a good idea though but in case I want the user to enter *username
> and password* on the Windows screen then It would fail.
>
> *Can't save username and password on the user-mapping.xml file for
> security purposes.*
>
I would not use the user-mapping.xml file for the size of production
environment that you're using. First, I'm not certain that the tokens
(${GUAC_USERNAME} and ${GUAC_PASSWORD}) actually work with the simple/basic
file authentication mechanism. Mike can verify this. Second, storing
usernames/passwords in user-mapping.xml for 500 users seems like a bad idea.
If you're considering scaling to this level, I suggest using one or more of
the extension modules for authentication - at least the JDBC module, and
perhaps that in combination with something, like LDAP. If you're using
active directory for the Windows servers you're connecting to this makes a
lot of sense, because the username/password used to log in to Guacamole
will match to the servers you're logging into. If you're not, it still
might make sense to track users in some sort of database - either JDBC or
LDAP - as this will provide continuity across the environment.
-Nick
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Amarjeet Singh <am...@gmail.com>.
If I don't pass username and password then ${GUAC_USERNAME} fails to
resolve [ *Scenario : I want users to enter username and password on
Windows screen* ]. It create directory with it's own name i.e.
${GUAC_USERNAME}
So, Creating filesystem solved this issue and It created directories of
users at runtime using "*enable-create-drive*" parameter.
Now, I need to look into the following to achieve quotas per sub-volumes or
each user's directory. :-
ZFS or btrfs, for example, allow for sub-volumes and quotas per-volume,
> per-user, and/or per-group
>
Using SFTP is a good idea though but in case I want the user to
enter *username
and password* on the Windows screen then It would fail.
*Can't save username and password on the user-mapping.xml file for security
purposes.*
On Sun, Jan 7, 2018 at 7:24 PM, Nick Couchman <vn...@apache.org> wrote:
> On Sat, Jan 6, 2018 at 3:21 PM, Mike Jumper <mi...@guac-dev.org>
> wrote:
>
>> On Sat, Jan 6, 2018 at 12:10 PM, Amarjeet Singh <am...@gmail.com>
>> wrote:
>>
>>> Hi Mike,
>>>
>>> Use separate filesystems to hold the drive
>>>
>>> contents, not the root filesystem of your Guacamole server.
>>>
>>>
>>>
>>> If I have 500 users then I can't have separate file system for each one
>>> of them on the same machine where guacamole server runs [ centos 7 ] .
>>>
>>>
>> Can't or won't? ;)
>>
>> If you wanted to, you probably actually could do this (write an extension
>> to dynamically create a temporary filesystem on a per-connection basis
>> which is cleaned up upon disconnect), but I meant that you could create a
>> single separate file system to isolate the overall base for all users'
>> drives. If a number of users end up using way too much space, then the
>> damage is limited to just RDP drive usage, and the rest of your server is
>> unaffected.
>>
>>
> ...and this should be pretty easy to manage with some of the newer
> filesystems - ZFS or btrfs, for example, allow for sub-volumes and quotas
> per-volume, per-user, and/or per-group. So, it should be relatively
> straight-forward to create a filesystem or volume that has home directories
> for each user and that can be passed using the ${GUAC_USERNAME} token, as
> Mike mentioned,
>
> Alternatively, if you make the user directories available via SFTP (e.g.
> on another Linux fileserver) you can enable SFTP support, use AD domain
> authentication on the Linux server, and enable SFTP on the connection using
> the same username/password (tokens, for example) as they are using to log
> into the connection.
>
> Point is...there are many ways to accomplish what you are trying to do
> with minimal administrative burden.
>
> -Nick
>
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Nick Couchman <vn...@apache.org>.
On Sat, Jan 6, 2018 at 3:21 PM, Mike Jumper <mi...@guac-dev.org>
wrote:
> On Sat, Jan 6, 2018 at 12:10 PM, Amarjeet Singh <am...@gmail.com>
> wrote:
>
>> Hi Mike,
>>
>> Use separate filesystems to hold the drive
>>
>> contents, not the root filesystem of your Guacamole server.
>>
>>
>>
>> If I have 500 users then I can't have separate file system for each one
>> of them on the same machine where guacamole server runs [ centos 7 ] .
>>
>>
> Can't or won't? ;)
>
> If you wanted to, you probably actually could do this (write an extension
> to dynamically create a temporary filesystem on a per-connection basis
> which is cleaned up upon disconnect), but I meant that you could create a
> single separate file system to isolate the overall base for all users'
> drives. If a number of users end up using way too much space, then the
> damage is limited to just RDP drive usage, and the rest of your server is
> unaffected.
>
>
...and this should be pretty easy to manage with some of the newer
filesystems - ZFS or btrfs, for example, allow for sub-volumes and quotas
per-volume, per-user, and/or per-group. So, it should be relatively
straight-forward to create a filesystem or volume that has home directories
for each user and that can be passed using the ${GUAC_USERNAME} token, as
Mike mentioned,
Alternatively, if you make the user directories available via SFTP (e.g. on
another Linux fileserver) you can enable SFTP support, use AD domain
authentication on the Linux server, and enable SFTP on the connection using
the same username/password (tokens, for example) as they are using to log
into the connection.
Point is...there are many ways to accomplish what you are trying to do with
minimal administrative burden.
-Nick
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sat, Jan 6, 2018 at 12:10 PM, Amarjeet Singh <am...@gmail.com>
wrote:
> Hi Mike,
>
> Use separate filesystems to hold the drive
>
> contents, not the root filesystem of your Guacamole server.
>
>
>
> If I have 500 users then I can't have separate file system for each one of
> them on the same machine where guacamole server runs [ centos 7 ] .
>
>
Can't or won't? ;)
If you wanted to, you probably actually could do this (write an extension
to dynamically create a temporary filesystem on a per-connection basis
which is cleaned up upon disconnect), but I meant that you could create a
single separate file system to isolate the overall base for all users'
drives. If a number of users end up using way too much space, then the
damage is limited to just RDP drive usage, and the rest of your server is
unaffected.
You can use the "${GUAC_USERNAME}" token cause a parameter to vary by
>> the username, like the "drive-path" parameter. Together with the
>> "create-drive-path" parameter, this allows you to dynamically provide
>> separate drives on a per-user basis.
>
>
> where exactly I have to do ? Where do I have to change this or add ${GUAC_USERNAME}.
> Is it in Javascript or Java.
>
>
Neither - it's connection configuration data. You would specify it for the
"drive-path" parameter of the connection in question. If you're using the
web interface to manage your connections, this is the connection parameter
labeled "Drive path". For example, instead of:
/some/drive/path
you would specify:
/some/drive/path/${GUAC_USERNAME}
When a user attempts to connect using that connection, their username will
be automatically substituted. Read through the "parameter tokens" section
of the part of the manual covering connection configuration - it should be
relatively clear:
http://guacamole.apache.org/doc/gug/configuring-guacamole.html#parameter-tokens
- Mike
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Amarjeet Singh <am...@gmail.com>.
Hi Mike,
Use separate filesystems to hold the drive
contents, not the root filesystem of your Guacamole server.
If I have 500 users then I can't have separate file system for each one of
them on the same machine where guacamole server runs [ centos 7 ] .
You can use the "${GUAC_USERNAME}" token cause a parameter to vary by
> the username, like the "drive-path" parameter. Together with the
> "create-drive-path" parameter, this allows you to dynamically provide
> separate drives on a per-user basis.
where exactly I have to do ? Where do I have to change this or add
${GUAC_USERNAME}.
Is it in Javascript or Java.
How can I control the size limit for each user ?
Can I define volume size for each user ?
@Mike : Thanks for the quick response. I appreciate that. I read your side
note as well. I won't update the fix version of any bug reported by me ?
Really sorry for that mess.
Thanks and Regards,
Amarjeet Singh
On Sun, Jan 7, 2018 at 12:50 AM, Mike Jumper <mi...@guac-dev.org>
wrote:
> On Sat, Jan 6, 2018 at 10:58 AM, Amarjeet Singh <am...@gmail.com>
> wrote:
> >
> > Hi Team,
> >
> > I have redirected shared drive on Windows server 2012 R 2. I have 5
> users in that machine.
> >
> > I have mapped this drive to one of the folder of Centos 7 where
> guacamole server runs.
> >
> > Now, all the users are getting the same shared drive folder.
> >
>
> Sounds OK so far.
>
> >
> > It means one user can access files of other users. It is very dangerous.
> >
> > It is breach of security and privacy as well.
> >
> > Is it any configuration I am missing ?
> >
>
> Guacamole will only do what you tell it to do. If you configure the
> connection for each user to use the same drive directory, then each
> user will have equivalent access to the contents of that directory. If
> this is not what you want, then you need to tell Guacamole to do
> something else.
>
> The mechanism most users use to ensure that each user is given a
> different drive directory are parameter tokens:
>
> http://guacamole.apache.org/doc/gug/configuring-guacamole.
> html#parameter-tokens
>
> You can use the "${GUAC_USERNAME}" token cause a parameter to vary by
> the username, like the "drive-path" parameter. Together with the
> "create-drive-path" parameter, this allows you to dynamically provide
> separate drives on a per-user basis.
>
> Alternatively, you can write an extension for Guacamole which derives
> connection parameter data however you like, including populating the
> "drive-path" parameter dynamically based on the user, some unique
> value generated for that session, etc.
>
> >
> > Data of the user should be deleted once the session is disconnected
> otherwise it will occupy whole lot of space in the server [ where
> guacamole server runs ].
> >
>
> No, part of the point of Guacamole's virtual drive is that the data
> persists:
>
> http://guacamole.apache.org/doc/gug/using-guacamole.html#rdp-virtual-drive
>
> If you want data to be deleted after a user disconnects, you will need
> to implement that functionality outside of Guacamole or through an
> extension, though I really wouldn't recommend this. The Principle of
> Least Surprise being what it is, I don't imagine users being happy
> when their uploaded files mystically disappear.
>
> > It will definitely cause the server down.
> >
>
> No. If you provide your users with storage space, it does not
> immediately follow that your server will go down.
>
> If you intend to provide your users with storage, such as that
> provided by Guacamole's virtual drive, and you are concerned that they
> may use up disk space, you will need to architect that storage such
> that this is not an issue. Use separate filesystems to hold the drive
> contents, not the root filesystem of your Guacamole server.
>
> >
> > Every user 's shared drive should not be same.
> >
>
> If you do not want the shared drive to be the same, it must be
> configured to be different. See above.
>
> > And we cannot assign 50 user different folder location every time.
> >
>
> You can, though for 5 users I'd recommend 5, not 50. You can do this
> automatically, through the "${GUAC_USERNAME}" token or through writing
> your own extension to handle this, or manually, through creating 5
> separate connections. I would recommend the automatic route.
>
> - Mike
>
Re: Same shared Drive redirected to all users : Privacy and Security breach
Posted by Mike Jumper <mi...@guac-dev.org>.
On Sat, Jan 6, 2018 at 10:58 AM, Amarjeet Singh <am...@gmail.com> wrote:
>
> Hi Team,
>
> I have redirected shared drive on Windows server 2012 R 2. I have 5 users in that machine.
>
> I have mapped this drive to one of the folder of Centos 7 where guacamole server runs.
>
> Now, all the users are getting the same shared drive folder.
>
Sounds OK so far.
>
> It means one user can access files of other users. It is very dangerous.
>
> It is breach of security and privacy as well.
>
> Is it any configuration I am missing ?
>
Guacamole will only do what you tell it to do. If you configure the
connection for each user to use the same drive directory, then each
user will have equivalent access to the contents of that directory. If
this is not what you want, then you need to tell Guacamole to do
something else.
The mechanism most users use to ensure that each user is given a
different drive directory are parameter tokens:
http://guacamole.apache.org/doc/gug/configuring-guacamole.html#parameter-tokens
You can use the "${GUAC_USERNAME}" token cause a parameter to vary by
the username, like the "drive-path" parameter. Together with the
"create-drive-path" parameter, this allows you to dynamically provide
separate drives on a per-user basis.
Alternatively, you can write an extension for Guacamole which derives
connection parameter data however you like, including populating the
"drive-path" parameter dynamically based on the user, some unique
value generated for that session, etc.
>
> Data of the user should be deleted once the session is disconnected otherwise it will occupy whole lot of space in the server [ where guacamole server runs ].
>
No, part of the point of Guacamole's virtual drive is that the data persists:
http://guacamole.apache.org/doc/gug/using-guacamole.html#rdp-virtual-drive
If you want data to be deleted after a user disconnects, you will need
to implement that functionality outside of Guacamole or through an
extension, though I really wouldn't recommend this. The Principle of
Least Surprise being what it is, I don't imagine users being happy
when their uploaded files mystically disappear.
> It will definitely cause the server down.
>
No. If you provide your users with storage space, it does not
immediately follow that your server will go down.
If you intend to provide your users with storage, such as that
provided by Guacamole's virtual drive, and you are concerned that they
may use up disk space, you will need to architect that storage such
that this is not an issue. Use separate filesystems to hold the drive
contents, not the root filesystem of your Guacamole server.
>
> Every user 's shared drive should not be same.
>
If you do not want the shared drive to be the same, it must be
configured to be different. See above.
> And we cannot assign 50 user different folder location every time.
>
You can, though for 5 users I'd recommend 5, not 50. You can do this
automatically, through the "${GUAC_USERNAME}" token or through writing
your own extension to handle this, or manually, through creating 5
separate connections. I would recommend the automatic route.
- Mike