gmane.linux.ubuntu.hardened.general

Re: authenticated NTP

Marc Deslauriers — 2012-02-23T19:59:43

ntpd has a panic threshold which is 1000 seconds by default. Does
ntpdate have an equivalent feature? Maybe adding one that won't make the
clock go back or forward more than a day or two would be a good idea
until we get something better?

Marc.

Re: authenticated NTP

Kees Cook — 2012-02-23T19:57:02

You started a discussion; I don't think that counts as being ignored. :)

I'd say, it's a known issue, but not high priority, and there doesn't seem to be a
standard way to use authentication with the default ntp pool.

Re: authenticated NTP

2012-02-23T18:42:29

I aware of it, but I was more hoping for an official statement from the
security team... Like for example...
"We already use authenticated NTP."
"Authenticated NTP is planed."
"We would like to use authenticated NTP, but we can't..."
"Unauthenticated NTP can not be used for MITM, it is already secure, you
are paranoid, get lost."

But I am mostly ignored and the interest in this topic seams very little.

Re: authenticated NTP

dave bl — 2012-02-21T14:12:21

You might be interested in https://github.com/ioerror/tlsdate, "secure
parasitic rdate replacement".
Although, it probably isn't "ready for use production use TM".

--
David.

Re: authenticated NTP

2012-02-20T15:47:28

It's really strange that this topic gets so less attention.

I am sorry, information is very hard to find on Google. Here are two
links, how to set up authenticated NTP as a client.
https://ntp3.sp.se/howto.html
http://support.ntp.org/bin/view/Support/ConfiguringAutokey

What I have not found yet, is a free, public NTP server, not to speak
about a whole list. Only a few servers in the NTP pool do support it. This
is probable not going to change, if we do not discuss it.

Re: authenticated NTP

Kees Cook — 2012-02-20T01:23:59

Do you have an example of doing this with the public NTP pool?

Thanks!

-Kees

authenticated NTP

2012-02-19T22:26:44

Why Ubuntu does not use authenticated NTP by default?

Unauthenticated NTP is dangerous, for example, a MITM can forge the NTP
reply, switch the date back and use old/revoked SSL certificates.

Re: [kernel-hardening] Re: Add overflowprotection to kref

Greg KH — 2012-02-17T17:53:22

Can we switch it on those arches where it is an atomic operation?  That
would be a nice simple solution.

thanks,

greg k-h

Add overflow protection to kref

David Windsor — 2012-02-16T14:02:13

Hi,

We are attempting to add various grsecurity/PAX features to upstream
Ubuntu kernels.

The PAX folks added refcount overflow protection by inserting
architecture-specific code in the increment paths of atomic_t.  For
instance:

static inline void atomic_inc(atomic_t *v)
 {
asm volatile(LOCK_PREFIX "incl %0\n"

#ifdef CONFIG_PAX_REFCOUNT
     "jno 0f\n"
     LOCK_PREFIX "decl %0\n"
     "int $4\n0:\n"
     _ASM_EXTABLE(0b, 0b)
#endif

     : "+m" (v->counter));
}

There are two distinct classes of users we need to consider here:
those who use atomic_t for reference counters and those who use
atomic_t for keeping track of statistics, like performance counters,
etc.; it makes little sense to overflow a performance counter, so we
shouldn't subject those users to the same protections as imposed on
actual reference counters.  The solution implemented by PAX is to
create a family of *_unchecked() functions and to patch
statistics-based users of atomic_t to use this interface.

PAX refcount overflow protection was developed before kref was
created.  I'd like to move overflow protection out of atomic_t and
into kref and gradually migrate atomic_t users to kref, leaving
atomic_t for those users who don't need overflow protection (e.g.
statistics-based counters).

I realize that there are many users of atomic_t needing overflow
protection, but the move to kref seems like the right thing to do in
this case.

Leaving the semantics of overflow detection aside for the moment, what
are everyone's thoughts on adding overflow protection to kref rather
than to atomic_t?

Also, I cherrypicked the refcount protection feature directly from the
PAX patch, with the original atomic_t protections in place, before
considering kref.  If anyone is interested, I can post that patch.

Thanks,
David Windsor

Re: Sysctl for set_kernel_text_r[wo]

David Windsor — 2011-09-21T05:25:01

Hi Kees,

On Mon, Sep 19, 2011 at 1:12 AM, Kees Cook <kees< at >ubuntu.com> wrote:

I agree.  The only caller of set_kernel_text_r[wo] is ftrace, and only
dynamic ftrace at that.  When CONFIG_DYNAMIC_FTRACE is enabled, ftrace
modifies an in-core table of function pointers to mcount call sites.
AFAICS, when tracing filters are used, ftrace walks this table and
sets mcount call sites in functions not being traced to nops, so as to
minimize execution time penalties for non-traced code paths.
Similarly, in cases where CONFIG_DYNAMIC_FTRACE is set but tracing
isn't currently being performed, performance penalties are mitigated
by making all members of the mcount call site table a nop.

Both of these operations require kernel text to be writable, but since
ftrace is the only user of the set_kernel_text_r[wo] and
set_all_modules_text_r[wo], why don't we at least guard the definition
of these interfaces with #ifdefs for CONFIG_DYNAMIC_FTRACE?  At least
this way, users for whom security is a concern (who also will not be
using ftrace), won't have these interfaces available for ROP attacks.
Currently, calls to these functions are guarded by #ifdefs but their
definition isn't.

I've included a patch that guards the definition of
set_kernel_text_r[wo] and set_all_modules_text_r[wo] with #ifdefs for
CONFIG_DYNAMIC_FTRACE.  I have not tested this patch.

Thanks,
David

 arch/x86/include/asm/cacheflush.h |    2 ++
 arch/x86/mm/init_32.c             |    2 ++
 arch/x86/mm/init_64.c             |    2 ++
 include/linux/module.h            |    2 +-
 kernel/module.c                   |    2 ++
 5 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/cacheflush.h
b/arch/x86/include/asm/cacheflush.h
index 4e12668..ff4e7a0 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
< at >< at > -146,12 +146,14 < at >< at > void clflush_cache_range(void *addr, unsigned int size);
 void mark_rodata_ro(void);
 extern const int rodata_test_data;
 extern int kernel_set_to_readonly;
+#ifdef CONFIG_DYNAMIC_FTRACE
 void set_kernel_text_rw(void);
 void set_kernel_text_ro(void);
 #else
 static inline void set_kernel_text_rw(void) { }
 static inline void set_kernel_text_ro(void) { }
 #endif
+#endif

 #ifdef CONFIG_DEBUG_RODATA_TEST
 int rodata_test(void);
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 29f7c6d..7e79965 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
< at >< at > -888,6 +888,7 < at >< at > EXPORT_SYMBOL_GPL(rodata_test_data);

 int kernel_set_to_readonly __read_mostly;

+#ifdef CONFIG_DYNAMIC_FTRACE
 void set_kernel_text_rw(void)
 {
 unsigned long start = PFN_ALIGN(_text);
< at >< at > -915,6 +916,7 < at >< at > void set_kernel_text_ro(void)

 set_pages_ro(virt_to_page(start), size >> PAGE_SHIFT);
 }
+#endif

 static void mark_nxdata_nx(void)
 {
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index bbaaa00..4a446d9 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
< at >< at > -733,6 +733,7 < at >< at > EXPORT_SYMBOL_GPL(rodata_test_data);

 int kernel_set_to_readonly;

+#ifdef CONFIG_DYNAMIC_FTRACE
 void set_kernel_text_rw(void)
 {
 unsigned long start = PFN_ALIGN(_text);
< at >< at > -768,6 +769,7 < at >< at > void set_kernel_text_ro(void)
  */
 set_memory_ro(start, (end - start) >> PAGE_SHIFT);
 }
+#endif

 void mark_rodata_ro(void)
 {
diff --git a/include/linux/module.h b/include/linux/module.h
index 1c30087..493d26c 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
< at >< at > -721,7 +721,7 < at >< at > extern int module_sysfs_initialized;

 #define __MODULE_STRING(x) __stringify(x)

-#ifdef CONFIG_DEBUG_SET_MODULE_RONX
+#ifdef CONFIG_DEBUG_SET_MODULE_RONX && CONFIG_DYNAMIC_FTRACE
 extern void set_all_modules_text_rw(void);
 extern void set_all_modules_text_ro(void);
 #else
diff --git a/kernel/module.c b/kernel/module.c
index 04379f92..edbedcb 100644
--- a/kernel/module.c
+++ b/kernel/module.c
< at >< at > -1667,6 +1667,7 < at >< at > static void unset_module_init_ro_nx(struct module *mod)
 set_memory_rw);
 }

+#ifdef CONFIG_DYNAMIC_FTRACE
 /* Iterate through all modules and set each module's text as RW */
 void set_all_modules_text_rw(void)
 {
< at >< at > -1708,6 +1709,7 < at >< at > void set_all_modules_text_ro(void)
 }
 mutex_unlock(&module_mutex);
 }
+#endif
 #else
 static inline void set_section_ro_nx(void *base, unsigned long
text_size, unsigned long ro_size, unsigned long total_size) { }
 static void unset_module_core_ro_nx(struct module *mod) { }

Re: Sysctl for set_kernel_text_r[wo]

Kees Cook — 2011-09-19T05:12:39

Hi David,

On Sun, Sep 18, 2011 at 09:42:59PM -0400, David Windsor wrote:

It would be really nice to be able to wipe these functions out. I really
dislike that they are available as such perfect ROP targets.


I haven't spent too much time looking into it, but I was under the
impression that the module loader used some of the underlying functions
too. Have you checked those code paths?

-Kees

Sysctl for set_kernel_text_r[wo]

David Windsor — 2011-09-19T01:42:59

Hi,

I am looking into adding a sysctl that enables toggling of
set_kernel_text_rw, set_kernel_text_ro.  It appears that the only
caller of these methods is ftrace, which can rather easily be disabled
when these methods are unavailable.

I'm afraid I'm overlooking something major here.  It seems that such a
control would have been added much earlier if it was actually as
simple as adding a guard variable, mutable via a sysctl, allowing
access to this interface.

Thanks,
David Windsor

Re: OVAL/XCCDF for Ubuntu

Marc Deslauriers — 2011-09-17T11:24:23

Sure. The pickle database was for our own use, but if anyone wants to
work on something to generate OVAL data, we'll gladly provide a json
format.

Marc.

Re: OVAL/XCCDF for Ubuntu

dave bl — 2011-09-17T09:58:36

On 17 September 2011 06:05, Marc Deslauriers
<marc.deslauriers< at >canonical.com> wrote:


Hum perhaps a "sane" information format could also be made available?
(if others want to use the data)
While pickle may work "fine tm" from python it will not play with
other languages as nicely as say json. It is also a "bad idea tm" to
load pickles you have not dumped your self.[0]

[0] http://nadiana.com/python-pickle-insecure

Re: OVAL/XCCDF for Ubuntu

Marc Deslauriers — 2011-09-16T20:05:06

Hi Vincent,

On Fri, 2011-09-16 at 15:54 -0400, Vincent Batts wrote:


We track our CVE information in this repository:
https://launchpad.net/ubuntu-cve-tracker

We also have a python pickle database that contains all the USNs we've
published, including descriptions and package versions. The database is
located here:

http://people.canonical.com/~ubuntu-security/usn/database.pickle

The tools in the ubuntu-cve-tracker are used to generate that database,
and can be looked at to gain knowledge of it's structure.

I think it would be fairly easy to write a python tool to parse the
pickle and automatically generate the OVAL metadata for Ubuntu updates.

Marc.

OVAL/XCCDF for Ubuntu

Vincent Batts — 2011-09-16T19:54:32

howdy all,

After a brief discussion with sbeattie, kees and mdeslaur, in the
#ubuntu-hardened irc channel, I understand that there are no official
efforts to establish a OVAL and/or XCCDF for ubuntu releases. There
are an increasing amount of utilities to generate reports, or execute
tests from these file formats. One of which is openscap
(http://www.open-scap.org/). A lot of it's efforts come from the
redhat community.

Question to the community, are there any groups currently working on
OVAL/XCCDF files, that would be willing to share?

mdeslaur,
you mentioned access to the USN database, that might get accessed in
an effort to generate these files. Can you provide more information on
that?

Take care,
vb

Re: [PATCH] policycoreutils: preserve mode bits and ownership of /tmp in seunshare

dave w — 2011-09-15T21:07:25

On Thu, Sep 15, 2011 at 4:07 PM, Guido Trentalancia
<guido< at >trentalancia.com> wrote:

Perhaps, but distros that install seunshare at present will be made
safer with the addition of a patch which eliminates an attack vector
to a privilege escalation.


Yes, the patch has been effective and with it applied, unprivileged
users cannot delete files other than their own from /tmp, which is the
expected behavior in a directory with the sticky bit set owned by the
superuser.

[PATCH] policycoreutils: preserve mode bits andownership of /tmp in seunshare

dave w — 2011-09-15T17:39:11

Hi,

This patch addresses a flaw in seunshare.c that allows unprivileged
users to arbitrarily modify the contents of /tmp.  This bug is further
described in CVE 2011-1011
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1011):

The seunshare_mount function in sandbox/seunshare.c in seunshare in certain
Red Hat packages of policycoreutils 2.0.83 and earlier in Red Hat
Enterprise Linux (RHEL) 6 and earlier, and Fedora 14 and earlier, mounts a
new directory on top of /tmp without assigning root ownership and the
sticky bit to this new directory, which allows local users to replace or
delete arbitrary /tmp files, and consequently cause a denial of service or
possibly gain privileges, by running a setuid application that relies on
/tmp, as demonstrated by the ksu application

This patch preserves the mode bits, and thus permissions, and
ownership of the destination directory of the bind mount performed by
seunshare.  The permission check in verify_mount() was relaxed for
directories who originally had the sticky bit set, as root ownership
is required for these to ensure that unprivileged users cannot unlink
arbitrary files in the newly bind mounted directory.

Thanks,
David



 policycoreutils/sandbox/seunshare.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/policycoreutils/sandbox/seunshare.c
b/policycoreutils/sandbox/seunshare.c
index f9bf12c..82b3cb9 100644
--- a/policycoreutils/sandbox/seunshare.c
+++ b/policycoreutils/sandbox/seunshare.c
< at >< at > -149,7 +149,9 < at >< at > static int verify_mount(const char *mntdir, struct
passwd *pwd) {
        fprintf(stderr, _("Invalid mount point %s: %s\n"), mntdir,
strerror(errno));
        return -1;
    }
-   if (sb.st_uid != pwd->pw_uid) {
+
+    /* Owners don't have to match if the sticky bit has been set. */
+   if (sb.st_uid != pwd->pw_uid && !(sb.st_mode && S_ISVTX)) {
        errno = EPERM;
        syslog(LOG_AUTHPRIV | LOG_ALERT, "%s attempted to mount an
invalid directory, %s", pwd->pw_name, mntdir);
        perror(_("Invalid mount point, reporting to administrator"));
< at >< at > -245,8 +247,17 < at >< at > static int verify_shell(const char *shell_name)
 }

 static int seunshare_mount(const char *src, const char *dst, struct
passwd *pwd) {
+    struct stat buf;
+
    if (verbose)
        printf("Mount %s on %s\n", src, dst);
+
+    /* Preserve mode bits and ownership */
+    if (stat(dst, &buf) < 0) {
+        fprintf(stderr, _("Failed to stat %s: %s\n"), dst, strerror(errno));
+        return -1;
+    }
+
    if (mount(dst, dst,  NULL, MS_BIND | MS_REC, NULL) < 0) {
        fprintf(stderr, _("Failed to mount %s on %s: %s\n"), dst, dst,
strerror(errno));
        return -1;
< at >< at > -262,6 +273,16 < at >< at > static int seunshare_mount(const char *src, const
char *dst, struct passwd *pwd)
        return -1;
    }

+    /* Restore original mode bits and ownership */
+    if (chmod(dst, buf.st_mode) < 0) {
+        fprintf(stderr, _("Failed to set permissions on %s: %s\n"),
dst, strerror(errno));
+        return -1;
+    }
+    if (chown(dst, buf.st_uid, buf.st_gid) < 0) {
+        fprintf(stderr, _("Failed to set ownership on %s: %s\n"),
dst, strerror(errno));
+        return -1;
+    }
+
    if (verify_mount(dst, pwd) < 0)
        return -1;
 }

tomld: fully automatic MAC configuration solution

Horvath Andras — 2011-07-27T06:36:56

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Members,

I'd like to announce the availability of the first beta release of my
tomld project.

This is a deamon managing fully automatic MAC configuration without any
user interaction.

(supported platforms are: Debian 6 and up, Ubuntu 10.10 and up)

My site:
http://log69.com/tomld_en.html

FAQ:
http://log69.com/help_en.html

Screenshot:
http://log69.com/images/tomld.png

You can also find a video of a quick installation:
http://www.youtube.com/watch?v=8pfjuU94of4
http://log69.com/extras/tomld038_ubuntu1104_install.ogv

The code is in beta status, but I'm already using and testing it in
smaller production environments. Once i have a stable version, I'll get
it into Debian as a package.

Every suggestion and feedback are welcome!


Regards,

Andras Horvath
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk4vsggACgkQAx9+mHylNBg7rACfRRVVcaVoPfr35vM2X5GpkWXY
CNsAn2o9/iFc/mFDhyyF/r0brwnuliHO
=4sR0
-----END PGP SIGNATURE-----

Re: Firewall settings: User interface review andquestions

Jim Tarvid — 2011-06-23T18:30:15

As one of the guys with boots on the ground, this discussion fails to
recognize real world issues.

In our practice, primary focus of security is on gateways not
individual machines. Some of these gateways are appliances, many of
those run DD-WRT or Open-WRT, others are Ubuntu servers. Better
integration with appliance gateways would be welcome.

The Ubuntu gateways are firewalled and depend on netfilter. The most
convivial interface for us has been Webmin. An amazing amount of
effort has been spent on alternatives to and deprecation of Webmin.
After getting burned by this apostasy, I am reluctant to enter that
battle. Webmin works for me.

I need to insure administrative access for a handful of machines,
access to a few public servers, deny access to a substantial number of
hostile subnets and permit my users to do largely do what they want in
peace.

Jim Tarvid

Re: Firewall settings: User interface review and questions

Jamie Strandboge — 2011-06-23T18:30:05

Indeed, Mathieu and I have been in discussions about this and I have a
work item already. :)


ufw takes these into account as well. When it is enabled and in
enforcing mode, it allows dhcp, avahi, ping and some other stuff that is
generally needed. For a full list, see /etc/ufw/before*.rules


The ufw API and cli command do not currently expose turning off these
'essential' connection types. I don't think it is worthwhile exposing
this in the gui. ufw uses good defaults for most people. Those who need
more can edit the /etc/ufw/before*rules directly IMHO.


This is correct. The ufw API and cli command do provide for egress
filtering though, so this could be exposed in the gui if desired. In
general I don't think this needs to be exposed in the gui.


This could conceivably be revisited if there was a gui tool to adjust
the firewall. In general, I think opting into the firewall is a good
idea since people have the chance to realize if something breaks it is
because of something they did. ufw does have debconf functionality for
preseeding (enable/disable and basic opening of ports), so it is
possible to add a question in ubiquity if desired, though I'm not sure
that is desirable if the firewall configuration is easily discoverable
via network manager.