User privacy

Tue Feb 16 20:19:53 UTC 2021

On Tue, 2021-02-16 at 19:33 +0000, Chris Green wrote:
> On Tue, Feb 16, 2021 at 08:02:02PM +0100, Volker Wysk wrote:
> > Am Dienstag, den 16.02.2021, 12:21 -0500 schrieb Robert Heller:
> > > At Tue, 16 Feb 2021 17:37:21 +0100 "Ubuntu user technical
> > > support, not 
> > for general discussions" <ubuntu-users at lists.ubuntu.com> wrote: 
> > > > Content-Type: text/plain
> > > > Am Dienstag, den 16.02.2021, 15:54 +0000 schrieb Chris Green:
> > > > > On Tue, Feb 16, 2021 at 04:35:57PM +0100, Volker Wysk wrote:
> > > > > > Am Dienstag, den 16.02.2021, 23:23 +0800 schrieb Bret
> > > > > > Busby:
> > > > > > > On 16/02/2021, Volker Wysk <post at volker-wysk.de> wrote:
> > > > > > > > Hi
> > > > > > > > Am Dienstag, den 16.02.2021, 14:18 +0000 schrieb Ian
> > > > > > > > Bruntlett:
> > > > > > > > > Hi,
> > > > > > > > > I'm sorting out an existing Lubuntu 18.04 laptop for
> > > > > > > > > a mother anddaughter. At the moment when I run umask
> > > > > > > > > I get the result "0002" which Ibelieve means that
> > > > > > > > > different users can read each other's files in
> > > > > > > > > their$HOME directories. They want to stop each other
> > > > > > > > > from reading their files.
> > > > > > > > > Now I have a rough idea on how to arrange this. I
> > > > > > > > > believe a differentumask value has to be specified
> > > > > > > > > however I don't know:-* What value of umask to use*
> > > > > > > > > Where to set that value so that it is set as the
> > > > > > > > > default onbootup/login.
> > > > > > > > 
> > > > > > > > You don't need to touch the umask. Just delete the
> > > > > > > > permissions for "others"on the home directories:
> > > > > > > > chmod o-rwx /home/HOMEDIR1chmod o-rwx /home/HOMEDIR2
> > > > > > > > Bye,Volker
> > > > > > > 
> > > > > > > Is it "others" or "group"?
> > > > > > > I preferred it when it was numbers; the 777 system, so,
> > > > > > > for example,chmod 007
> > > > > > 
> > > > > > It's "others". Each user should have its own private group
> > > > > > with the samename as the user name and only that user in
> > > > > > it. So the group ownership orpermissions should not be a
> > > > > > problem.
> > > > > It always seems to be a rather strange default set-up to
> > > > > configureevery new user to have a group of their own.  It
> > > > > makes the whole ideaof groups in permissions rather
> > > > > redundant!
> > > > 
> > > > Not at all. You still can create groups, if you want to share
> > > > something, orwant to grant access rights to something to
> > > > specific users. You just don'tshare anything by default. Its
> > > > more secure this way.
> > > > > It *may* be a good idea to configure things so that, by
> > > > > default, filesdon't have group read permission (i.e. umask
> > > > > 002, I *think*) but oneoften *does* want to share files for
> > > > > reading and that requires thatusers belong to some common
> > > > > groups.  They can then set group readpermission on files they
> > > > > want to share.
> > > > 
> > > > Yes, just add a group named "users" with all the users in it.
> > > > Then they canset the group ownership to "users" for files they
> > > > want to share between allusers. But they must do so explicitly,
> > > > and I think this is a good thing. 
> > > > Come to think of it, this also means those users will also have
> > > > to dosomething with their home directory group membership, when
> > > > they want toshare something inside their home directory. If it
> > > > has been configured toexclude "others", as I've advised
> > > > above...
> > > 
> > > chmod go+x ~
> > > (note: not r!)
> > > Execute on a directory allows directory traversal, but not read
> > > access.
> > 
> > That's right. You need to know the name of the file or directory
> > inside ~,and then you can access it, when its permissions allow it.
> > You could, forinstance, create a directory ~/shared, with world
> > read- and lookup (x)rights. 
> > The problem is, you also can guess names inside the ~, such as
> > .bashrc orbin/... When those don't deny read rights to "others",
> > they can be read...
> More to the point, does it *matter* if others can read what's there?
> Everyone in the world is welcome to the contents of my .bashrc
> file,I'd love them to be able to learn any morsels of information
> they canfind there.
> Default should be *ALLOW* access, hide the bits you think should
> behidden.  In a work situation I'd have thought nothing should
> behidden, what part of your work should be hidden from your
> colleagues? 

What? No, no, no! If you want a secure system, then operate on the
principal of least privilege, only allow others to see what they are
entitled to see or that you deliberately and specifically allow them to
see. Allowing access by default may be OK (I can think of examples
where it might not be) for your work colleagues, but what if one of
their accounts gets compromised and then the intruder can see all your
stuff which might include stuff people outside the company should not
see.

Examples of things you may want to keep private: a recently updated CV
which may give the impression you're about to leave the company;
details of your current salary/bonus; quotations from suppliers marked
commercial in confidence. You get the idea.

And protecting items you want to keep private is prone to error if
everything is accessible. Much better to permit access when necessary
than have access denied by default.

Regards,
Tony.
-- 
Tony Arnold MBCS, CITP | Senior IT Security Analyst | Directorate of IT Services | Office 1, Kilburn Building | The University of Manchester | Manchester M13 9PL | T: +44 161 275 6093 | M: +44 773 330 0039
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20210216/0bc59c89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4054 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20210216/0bc59c89/attachment.bin>