Is randomizing UID/GUID would make sense?

[minek van]

Hello!

I can see that the default users and when creating new ones have their UID/GUID 
incremented by 1. 

Could it bring more security if the UIDs/GUIDs would be random? 

Or it wouldn't bring any additional security? 

Or something would be broken with random UIDs/GUIDs, ex.: NFS? Would it only do 
pain? 

Thanks for any comments!

Re: {file,directory} permissions within /usr/{src,xenocara,ports}

[G]

For xenocara i followed the faq. For ports if you want to follow stable
then dpb worked with 777.It was 775 but dpb didnt work. I tried to
change the owner and permissions of {DISTDIR},{PORTSDIR} {WRKOBJDIR}
{PACKAGE_REPOSITORY} and {PLIST_REPOSITORY} to _pbuild but it still
failed to build the packages.This isnt probably the "best practices" but
port documentation is a bit old.

PS.I guess there is another directory  dpb need access or i made a
stupid mistake :-p



On 01/19/17 19:14, Jonathan Thornburg wrote:
> What are the "best practices" file and directory permissions within
> the /usr/{src,xenocara,ports} trees in the context of anonymous-cvs
> updating?
> 
> http://www.openbsd.org/faq/faq5.html#wsrc  suggests that the top-level
> directories /usr/{xenocara,ports} should be mode 775, but doesn't say
> what permissions subdirectories and individual files should have.  The
> current  {src,sys,ports,xenocara}.tar.gz  tarballs on my local mirror
> show files/directories being modes 644 and 755 respectively (both owned
> by deraadt/wheel in the tarball).  Unpacking these as a non-root user
> (in the wsrc group) as suggested by http://www.openbsd.org/anoncvs.html
> will leave permissions which depend on that user's umask.
> 
> Is the current "best practice" to create a separate user for source-tree
> cvs operations, or do do it as "myself" (already in wsrc, wheel, operator,
> and various other groups)?
> 
> Alternatively, is there a Fine Manual I've overlooked which documents
> this?
> 
> Thanks, ciao,

Re: xl2tpd connect problem

[Stuart Henderson]

On 2017-01-19, Jeremie Courreges-Anglas  wrote:
> Alex Mihajlov  writes:
>
>> Hi
>>
>> I have problem when I connect to my ISP with l2tp.
>
> An ISP that provides internet access via l2tp on the customer's
> equipment?  Fun...

We have one here too. It's quite handy if you need to get static IPs
or routed v4 or v6 blocks and the only people who can supply you with
decent bandwidth use dynamic IP addresses (or worse), or you can use
it for fallback etc.

>> l2tp connections with my phone runs without problem.
>> I use OpenBSD 6.0 and xl2tpd-1.3.1 from package.
>>
>> My configuration file:
>> $ /etc/xl2tpd/xl2tpd.conf
>> [global]
>> access control = yes
>> auth file = /etc/ppp/chap-secrets
>> force userspace = yes
>> debug network = yes
>> debug avp = yes
>> debug packet = yes
>> debug state = yes
>> debug tunnel = yes
>> ipsec saref = yes
>
> Why do you need "yes" here?  What happens if you set "no" instead?  The
> messages below suggest that the feature doesn't work on OpenBSD anyway.

yep. If you need IPsec + L2TP the IPsec side of things will need to be
configured separately.

>> [lac provider]
>> lns = ip_address
>> redial = yes
>> redial timeout = 2
>> autodial = yes
>> hidden bit = no
>> flow bit = yes
>> length bit = yes
>>
>> $ doas cat /etc/ppp/chap-secrets
>> username*   password *
>>
>> Debug log xl2tpd:
>> # xl2tpd -D
>> xl2tpd[90769]: Enabling IPsec SAref processing for L2TP transport mode SAs
>> xl2tpd[90769]: No attempt being made to use IPsec SAref's since we're not on 
>> a
>> Linux machine.

Did you send the command to connect? (Did you read the pkg-readme
that you were told about when you installed the package?)

{file,directory} permissions within /usr/{src,xenocara,ports}

[Jonathan Thornburg]

What are the "best practices" file and directory permissions within
the /usr/{src,xenocara,ports} trees in the context of anonymous-cvs
updating?

http://www.openbsd.org/faq/faq5.html#wsrc  suggests that the top-level
directories /usr/{xenocara,ports} should be mode 775, but doesn't say
what permissions subdirectories and individual files should have.  The
current  {src,sys,ports,xenocara}.tar.gz  tarballs on my local mirror
show files/directories being modes 644 and 755 respectively (both owned
by deraadt/wheel in the tarball).  Unpacking these as a non-root user
(in the wsrc group) as suggested by http://www.openbsd.org/anoncvs.html
will leave permissions which depend on that user's umask.

Is the current "best practice" to create a separate user for source-tree
cvs operations, or do do it as "myself" (already in wsrc, wheel, operator,
and various other groups)?

Alternatively, is there a Fine Manual I've overlooked which documents
this?

Thanks, ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" 

   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time."  -- George Orwell, "1984"

Re: xl2tpd connect problem

[Jeremie Courreges-Anglas]

Alex Mihajlov  writes:

> Hi
>
> I have problem when I connect to my ISP with l2tp.

An ISP that provides internet access via l2tp on the customer's
equipment?  Fun...

> l2tp connections with my phone runs without problem.
> I use OpenBSD 6.0 and xl2tpd-1.3.1 from package.
>
> My configuration file:
> $ /etc/xl2tpd/xl2tpd.conf
> [global]
> access control = yes
> auth file = /etc/ppp/chap-secrets
> force userspace = yes
> debug network = yes
> debug avp = yes
> debug packet = yes
> debug state = yes
> debug tunnel = yes
> ipsec saref = yes

Why do you need "yes" here?  What happens if you set "no" instead?  The
messages below suggest that the feature doesn't work on OpenBSD anyway.

> [lac provider]
> lns = ip_address
> redial = yes
> redial timeout = 2
> autodial = yes
> hidden bit = no
> flow bit = yes
> length bit = yes
>
> $ doas cat /etc/ppp/chap-secrets
> username*   password *
>
> Debug log xl2tpd:
> # xl2tpd -D
> xl2tpd[90769]: Enabling IPsec SAref processing for L2TP transport mode SAs
> xl2tpd[90769]: No attempt being made to use IPsec SAref's since we're not on a
> Linux machine.

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: IPPORT_RESERVED 'security' check in nfsd obsolete?

[Amelia A Lewis]

On Thu, 19 Jan 2017 15:51:53 +0100, Nicolas Schmidt wrote:
> Am 19.01.2017 um 12:21 schrieb Theo de Raadt :
> 
>>> Then may I suggest to add an option to disable this behaviour for specific
>>> mounts?
>> 
>> No.
>> 
>> NFS always required reserved ports.
> 
> Do you mean that the "reserved ports restriction" is required as part of the
> NFS protocol spec? I took a look at 
> https://tools.ietf.org/html/rfc7530 , but
> couldn't find anyhing related to that.

https://utcc.utoronto.ca/~cks/space/blog/unix/NFSReservedPorts

Re: IPPORT_RESERVED 'security' check in nfsd obsolete?

[Nicolas Schmidt]

Am 19.01.2017 um 12:21 schrieb Theo de Raadt :

>> Then may I suggest to add an option to disable this behaviour for specific
mounts
>> ounts?
>
> No.
>
> NFS always required reserved ports.

Do you mean that the "reserved ports restriction" is required as part of the
NFS protocol spec? I took a look at https://tools.ietf.org/html/rfc7530 , but
couldn't find anyhing related to that.

Re: IPPORT_RESERVED 'security' check in nfsd obsolete?

[Nicolas Schmidt]

> Am 19.01.2017 um 01:20 schrieb Theo de Raadt :
>
> No, this change will not be done.

Then may I suggest to add an option to disable this behaviour for specific
mounts? NetBSD provides the "-noresvport" flag for this. The following quote
is from the NetBSD man for exports:

"The -noresvport option specifies that NFS RPC calls for the filesystem do
not have to come from reserved ports. Normally, clients are required to use
reserved ports for operations. Using this option decreases the security of
your system."

Re: lastcomm doesn't filter with arguments?

[Craig Skinner]

Hi Jiri

On Wed, 18 Jan 2017 10:37:51 -0500 Jiri B wrote:
> it seems `lastcomm' doesn't filter if it gets arguments

>From what I see here, it filters multiple commands OR multiple users.


$ uname -mrsv
OpenBSD 6.0 GENERIC#1917 i386


$ lastcomm cp
cp -   sysadmin __ 0.00 secs Thu
Jan 19 06:38 (0:00:00.02)
cp -   operator __ 0.00 secs Thu
Jan 19 05:15 (0:00:00.00)


$ lastcomm cp cut
cp -   sysadmin __ 0.00 secs Thu
Jan 19 06:38 (0:00:00.02)
cp -   operator __ 0.00 secs Thu
Jan 19 05:15 (0:00:00.00)
cut-   operator __ 0.00 secs Thu
Jan 19 04:00 (0:00:00.91)
cut-S  root __ 0.02 secs Thu
Jan 19 01:30 (0:00:00.02)



$ lastcomm cp cut operator | tail
sh -S  operator __ 0.00 secs Thu
Jan 19 02:15 (0:00:00.05)
logger -   operator __ 0.00 secs Thu
Jan 19 02:15 (0:00:00.02)
uptime -   operator __ 0.00 secs Thu
Jan 19 02:15 (0:00:00.00)
sh -S  operator __ 0.00 secs Thu
Jan 19 02:00 (0:00:00.09)
logger -   operator __ 0.00 secs Thu
Jan 19 02:00 (0:00:00.05)
uptime -   operator __ 0.00 secs Thu
Jan 19 02:00 (0:00:00.03)
sh -S  operator __ 0.02 secs Thu
Jan 19 01:45 (0:00:00.05)
logger -   operator __ 0.02 secs Thu
Jan 19 01:45 (0:00:00.02)
uptime -   operator __ 0.00 secs Thu
Jan 19 01:45 (0:00:00.00)
cut-S  root __ 0.02 secs Thu
Jan 19 01:30 (0:00:00.02)


> or am I reading wrongly man page?

I don't think so.
--
Craig Skinner | http://linkd.in/yGqkv7